Tax code by vendor

I do purchase some services internationally. They do not collect our GST, but I have to pay GST to our authorities. My question is:

When I assign a tax code to the non-inventory item to purchase it would show up on the purchase / order invoice increasing the total amount payable. However, when I do not assign the tax code it would not increase my tax liability.
How can I solve this issue?

Is it a sort of reverse charge?

This is a simple situation. When you buy from a local supplier, you apply an appropriate tax code and the amount of the purchase invoice goes up. The tax is offset against taxes you collect from customers in the Tax payable account.

But when the GST will be billed to you by the customs or tax authority, you do not apply any tax code to the purchase. Instead, you enter a separate transaction with the authority as the payee, because it is a completely separate transactions between different parties. But for this, you need a custom, 100% tax code that applies the entire amount entered to the tax. Read about that here:

This perfectly clear for local suppliers. I have the issue with international suppliers. When I purchase from abroad I do not pay the taxes upfront to the supplier since they wouldn’t remit to the CRA (Canadian tax authorities). However, my tax liability should go up. I guess I need a tax code that posts against the tax liability account without payment to the vendor.

It is not a customs related item since there is no customs invoice involved due to the fact that I am purchasing intangible goods.

Any suggestions, please?


@beaverPC, what you describe is exactly what I addressed in response to your initial statement, “…I have to pay GST to our authorities.” Your statement implied the authority was giving you a bill for the tax. This is extremely common.

From your most recent post, it is clear that is not what is happening. You must apparently self-assess the tax and pay it. But that is also simple. What you describe is a reverse-charge tax. See

The Guide addresses reverse charge VAT. VAT is an offsetting tax, meaning input VAT is subtracted from output VAT. If the tax you are required to pay on the intangible good is similar, follow the procedure from the Guide exactly. If it is not offsetting, you will have to modify things slightly so the offset does not occur (or possibly use a correcting journal entry). I think the Guide will make the general concepts involved fairly easy to understand.

Thank you for the guidance. It solves my problem since when I declare my GST return I declare what I have received from customers on Sales and deduct as credits what I did pay on purchases. Since those numbers show in the tax transactions report I have what I need. It seems though that the tax summary report is not very useful since the totals don’t add up anymore. But that’s okay.

What do you mean by this? Please illustrate with a screen shot.

The numbers in the green loop show inconsistent values. It is common practise to verify that values in a table are consistent by cross-summing the values. The 3.27 under Tax on Sales skew this table. In addition the yellow high-lighted amount of Total Purchases is only a fictitious value.
Well, I can live with that. It’s ok.

While that can be a common procedure, it is only meaningful when a table is designed in way that supports the assumption that cross-summing has any purpose. In this case, that is not true.

The Tax Summary comprises rows summarizing transactions for unrelated tax codes. The purpose of each row is to yield the tax liability for each tax code. In the case of your Import custom tax code, the liability is correctly shown as zero. And since every transaction contributing to the liability was a purchase, everything shows up under the purchases columns except the reverse charged tax. Because it is opposite in sign, it shows up as a tax on sales.

The column sums are essentially meaningless on this report for your situation. In some circumstances (no reverse charged taxes), you could cross-sum, but that would only be a happy coincidence. They aren’t designed to cross-sum. So look at them as being there as a courtesy for other users in simpler situations.

The real issue here is terminology for column headings. Those have actually been changed over the years as the developer has searched unsuccessfully for headings that make sense under all circumstances. Various users have made competing suggestions. The only universally accurate headings would be some version of debits and credits, and those would be incomprehensible to almost everyone. So he settled on these.

I guess the ultimate message here is that the numbers on the report are accurate. Nothing is “fictitious.” Some of the figures just don’t relate to one another in the way you apparently expected them to. This is a report, not a spreadsheet.