Where does the 0.01 debit-credit difference in vouchers come from? Tax-inclusive back-calculation is the correct method

Kailing Technology · 2026-09-06

There is almost only one reason:Divide the tax-inclusive amount by (1 + tax rate) to calculate the tax-exclusive amount; the rounding error when the division is not exact is that one cent.. The correct approach is to take the actual tax amount printed on the invoice directly without participating in calculation, and derive the tax-exclusive amount by subtracting the tax from the tax-inclusive amount, so that debits and credits are absolutely balanced.

Incorrect algorithm and correct algorithm

First look at the wrong approach:

Incorrect: Tax-exclusive = Tax-inclusive ÷ (1 + tax rate) ← rounding when not divisible, generating errors Tax amount = Tax-inclusive - Tax-exclusive Example: Tax-inclusive 1000.00, tax rate 6% Tax-exclusive = 1000 ÷ 1.06 = 943.396226... → 943.40 Tax amount = 1000 - 943.40 = 56.60 But the tax amount printed on the invoice may be 56.60 or 56.61, which may not match

The correct approach is the reverse:

Correct: Tax amount = the actual tax amount printed on the invoice ← based on the invoice, not included in calculation. Amount excluding tax = tax-inclusive amount - tax amount ← derived by subtraction to ensure absolute balance. Example: tax-inclusive 1060.00, invoice-printed tax amount 60.00. Amount excluding tax = 1060.00 - 60.00 = 1000.00. Debit 1000.00 + 60.00 = credit 1060.00, absolutely balanced

Core principles:The tax amount on an invoice is an established fact, not something calculated。Accounting vouchers should faithfully reflect invoices, rather than recalculating them independently.

Why this one cent must be eliminated

Vouchers with unbalanced debits and credits cannot be posted at all; the general ledger system will directly reject them. Moreover, such errors are random—most documents are fine, but occasionally one has a problem, and during troubleshooting it is difficult to locate that it was caused by the algorithm.

What makes it worse is that if the system automatically "balances" the entry when generating the voucher (for example, stuffing the difference into a certain line), the books may look balanced, but the amount in that line won't match the invoice—and this problem will stay hidden until an audit or tax inspection exposes it.

The second pitfall when summarizing multiple lines

When a reimbursement form has multiple line items, there is another easily overlooked issue:Summarize first and then calculate tax, versus calculate tax line by line and then summarize; the results may differ by a few cents。

Three line items, each tax-inclusive at 100.00, 200.00, and 300.00, with a 6% tax rate calculated line by line and then summed: add the tax amounts of each line after rounding; sum first and then calculate tax: 600.00 calculated once as a whole; the results of the two methods may differ by 0.01 ~ 0.02

Neither of these two approaches is wrong, but It must be confirmed with finance to unify the definition and fixed in code as the only implementation. The biggest fear is that different modules use different algorithms, causing the same batch of data to fail to match in two places.

How to handle when there are only ordinary invoices

When obtaining a general invoice, input VAT cannot be deducted; the recommended practice is No splitting, the full tax-inclusive amount is recorded as an expense. This both conforms to the tax caliber and naturally avoids the rounding difference issue.

If your company is a small-scale taxpayer, all reimbursements do not need to split out input VAT, and this entire category of problems does not exist.

Checklist During Implementation

Before launch, it is recommended to confirm each of these points one by one: whether the tax-exclusive amount is calculated by the residual method; whether the tax amount is taken directly from the invoice recognition result; which basis is used for multi-line aggregation and whether it is globally unique; whether general invoices uniformly do not split tax; whether the system prohibits automatic balancing of differences.

Among these five, the easiest to miss are the third and fifth.

How is this scenario handled in Kailing Technology's expense control system?

The tax amount is taken directly from the invoice OCR recognition result; the tax-exclusive amount is derived by subtracting the tax amount from the tax-inclusive amount, ensuring absolute debit-credit balance in vouchers. The multi-line summary basis is globally unique and configurable, avoiding inconsistent results across different modules. Debit-credit balance verification is performed before voucher generation; if unbalanced, no voucher is generated and no automatic balancing of the difference is made, exposing problems at the draft stage.

Learn about the Kailing Technology expense control and reimbursement system →

Common Questions

Why can't you divide the tax-inclusive amount by 1 plus the tax rate?

Rounding errors when division is not exact can cause a one-cent difference between debit and credit, and the calculated tax amount may not match the tax amount printed on the invoice.

If the tax amount on the invoice does not match your own calculation, which one prevails?

The invoice shall prevail. The invoice tax amount is an established fact, and the voucher should faithfully reflect the invoice.

For multi-line details, should tax be calculated after summarizing first or line by line?

Either is acceptable, but the unified scope must be confirmed with finance and fixed in code as the only implementation; different modules must not use different algorithms.

Do ordinary invoices need to separate the tax amount?

Recommend not splitting; include the full tax-inclusive amount as an expense. General invoices' input VAT is not deductible, so splitting is meaningless and introduces rounding differences.