Aller au contenu principal

Sales Tax Posting on General Journals

When a general journal line carries a Sales Tax Group and an Item Sales Tax Group, the system does more than calculate a tax amount for reporting — it posts a real, balancing entry to the ledger. This page explains how that posting works end to end: how the tax direction is decided, how the tax amount and sign are calculated, and how the resulting entry reaches the Tax Payable or Tax Receivable account.

This applies to both places tax can originate on a journal: a manually entered general journal line, and an invoice posted from a subledger (Accounts Receivable or Accounts Payable). Both paths now produce the same balancing tax entry — see Two posting paths, one result below.

The three-step process​

Posting sales tax on a journal line happens in three steps:

  1. Determine the sales tax direction — is this tax recoverable (Receivable) or owed (Payable)?
  2. Determine the sales tax amount and its sign — how much tax, and does it move the same way as the line it belongs to?
  3. Post the tax to the ledger — which account, and debit or credit?

Step 1 — Determine the sales tax direction​

The direction depends on the account type of the party in the voucher, and whether the tax code applied is marked exempt.

Voucher account typeTax code is exemptDirection
VendorYesTax Free Purchase (no posting)
VendorNoSales Tax Receivable
CustomerYesTax Free Sale (no posting)
CustomerNoSales Tax Payable
LedgerYesTax Free Purchase (no posting)
Ledger, line is a debitNoSales Tax Receivable
Ledger, line is a creditNoSales Tax Payable

A voucher has exactly one tax direction — anchored on the Vendor or Customer line if one exists. A voucher is a single real-world transaction (one invoice, one payment); it cannot be simultaneously a purchase and a sale. So when a voucher includes a Vendor or Customer line, that line's account type governs the direction for every taxed line in the voucher — including a Ledger (expense) line that carries the tax code itself. Only a voucher made up entirely of Ledger lines falls back to the debit/credit rule in the table above, using the taxed line's own sign.

Vendor takes priority over Customer if, unusually, a voucher contains both.

Scope note: this system does not model a Project account type, nor Use Tax / intracom VAT / reverse-charge tax code categories — every tax code here resolves to a plain Receivable, Payable, or exempt direction.

Step 2 — Determine the sales tax amount and sign​

A line's Sales Tax Group and Item Sales Tax Group can intersect to more than one applicable tax code (for example, a state tax and a federal tax layered on the same line). Each code is calculated — and posted — independently:

  • Each code's tax amount is computed from its own rate against the line's base amount.
  • Each code is resolved to its own direction (normally the same for every code on a line, since direction depends on the voucher-level anchor, not the code — unless codes differ in exempt status).
  • Codes that resolve to the same Tax Payable or Tax Receivable account are combined into a single ledger entry; codes resolving to different accounts each get their own entry.

The sign of the amount follows the line it came from:

Journal line amountSales tax directionSales tax amount sign
Positive (debit)Sales Tax ReceivablePositive
Positive (debit)Sales Tax PayableNegative
Negative (credit)Sales Tax ReceivableNegative
Negative (credit)Sales Tax PayablePositive

Step 3 — Post the sales tax amount and account​

The resolved sign and direction together determine the final debit/credit entry and which account it goes to — the Tax Payable or Tax Receivable account configured on the tax code's Ledger posting group:

Sales tax directionSales tax amount signSales tax accountAmount on voucher
Sales Tax ReceivablePositiveTax Receivable accountDebit
Sales Tax ReceivableNegativeTax Receivable accountCredit
Sales Tax PayablePositiveTax Payable accountCredit
Sales Tax PayableNegativeTax Payable accountDebit

Working through the table: a tax entry always lands on the same debit/credit side as the line it belongs to, regardless of direction — Receivable or Payable only decides which account is used, not which side of the ledger.

Tax-exclusive vs. tax-inclusive entry​

Every journal name has an Amounts include sales tax setting, which controls how the amount typed on a line is interpreted.

Tax-exclusive (the default). The entered amount is the pre-tax base. Tax is calculated and posted on top of it — the line itself is untouched.

Example: enter 1,000 with a 5% tax code. The expense line posts 1,000 unchanged; a separate 50 entry posts to Tax Payable/Receivable. Whatever line balances against this one must be entered at the grossed-up total (1,050) for the voucher to balance.

Tax-inclusive. The entered amount is treated as the gross, tax-inclusive total. The system solves backward for the pre-tax base and the tax split, and reduces the line's own posted amount down to that base — so the line and its tax entry always sum back to what was typed.

Example: enter 1,000 (inclusive) with a 5% tax code. The base works out to 952.38 and the tax to 47.62; the expense line posts 952.38, the tax entry posts 47.62, and the two together still total 1,000 — matching the entered figure exactly.

The inclusive-mode backward solve currently supports flat-percentage and fixed-amount tax codes. A tax code using a compounding calculation origin (percentage-of-gross, or tax-on-tax) cannot be solved backward from a single inclusive figure and is rejected if used in inclusive mode.

Two posting paths, one result​

Tax reaches the general ledger from two different starting points in this system:

  • Subledger invoices (Accounts Receivable, Accounts Payable): the sales tax distribution is generated alongside the invoice's gross and net distributions when the invoice posts, and reaches the GL through the standard subledger-to-GL transfer.
  • General journals (manually entered lines, or any LedgerJournalHeader): the tax entry is posted directly by the same journal-posting step that creates the line's own main-account entry.

Both paths now resolve direction, amount, and account through the same rules described above, and both produce a real, balancing GL entry — there is no path where tax is calculated but never posted.

See also​