I’m working with a Tryton accounting period where:
the chart of accounts is correct (from an accounting perspective), and
the tax lines appear valid.
My income statement correctly aggregates the relevant accounts to SUM24. As a cross-check, I expected the tax code report to show the same tax base amount. However, I’m seeing a discrepancy:
SUM24 = TAX24 + X
After some investigation, I believe the difference X comes from an action I took early on: I created a credit note against a cancelled invoice using the wizard (this was done to fix earlier postings). The accounting result is correct and the expected tax lines exist.
However, the tax code base seems to ignore the base amount of the cancelled invoice, while it does include the credit note lines.
I have two questions:
Where is the filtering logic implemented?
Which model / method / domain determines whether a record contributes to the tax code report? I’d like to understand where the inclusion/exclusion is decided (e.g., by invoice state, move state, tax line state, etc.).
Is this behavior expected and consistent?
If the accounting entries and tax lines are correct, I would expect the tax report to be correct regardless of the invoice state. Is it expected that a tax report can differ from an income statement solely because an invoice is in a cancelled state?
If so, should Tryton prevent crediting a cancelled invoice (or at least warn) when it can lead to inconsistent totals between reports for the same period?
Ok, that means I credited that invoice, but that does not explain, why move 29 is ignored by the tax code statement but not the income statement, I am missing exactly the move and the 11 Euro as (base) income in the tax report. From my accounting point of view, these two numbers must be equal.
I have found the reason.
I use tax-cash module and the reporting period was not set. Probably because I activated the module or configured it after creating the move.
Solution for that problem is: Check whether you use tax_cash module and have a look at the reporting period.
I solved that, because I had the same problem today, when I added a payment for a customer invoice for December (payment date in Period 2025-12) and the reporting period in the tax line (for tax cash) was set to today() to the new fiscal year-first period 2026-01.
I assume that in
date = Transaction().context.get(
'payment_date', Date.today())
defaults to Date.today(), maybe because the fiscal year differs. It works correctly in the same fiscal year.
From my point of view the payment date should be the correct date for the move. I didn’t dig any deeper yet, because I don’t know which is the indented behavior.
