The Invoice Nobody Can Reconcile at Quarter-End
Quarter-end is four sums over a set of documents. What the underlying records must make possible for an accountant to re-add the quarter by hand, a fully checkable worked example, and what a counter billing system does not produce.
Quarter-end arrives and your accountant sends four questions. What did we sell. What tax was recorded against it. What came back. What is still outstanding. These sound like four simple requests and in a good system they are four queries. In most systems they are four afternoons, because the answers have to be assembled from documents by a person who trusts none of them.
The reason is not a missing feature. It is that an invoice, in many systems, is stored as a total with some supporting detail rather than as a set of values that add up in a particular order and can be taken apart again in the same order. A total is a conclusion. A reconciliation is a derivation. You cannot derive from a conclusion.
So the invoice is handed over, the accountant opens it, and reads the taxable values, the tax amounts, the discount, the total, and the credit notes that relate to it, and starts adding. If the arithmetic closes, the invoice is fine. If it does not, there is no way to find out which of the four numbers is wrong without going back to the counter and asking.
This article is about the arithmetic a business has to produce for its accountant, and about what the underlying records must make possible for a person to re-add it without trusting the system. It is not tax advice, and none of it decides what belongs on a return. NoxOrigin does not file GST returns, does not generate or submit returns, is not a tax authority, and is not certified. Your chartered accountant decides what the figures mean. The system's job is to make the figures add up in front of them.
The arithmetic your accountant has to be able to re-do
Strip away the terminology and a quarter-end reconciliation is a small number of sums performed over a set of documents. There is a taxable value per line. There is a tax amount per line, derived from the taxable value at a rate. Lines sum to a document taxable value. Line tax sums to a document tax amount. The two sum to a document total. Then credit notes are applied against the documents they reverse, and payments are applied against what is left.
That is all of it. Every additional thing a quarter-end query seems to require is either one of these sums performed across a range of documents, or a question about which documents belong in the range.
The reason this is worth writing an article about is that a system can hold every one of those numbers and still fail the test, if the relationship between them is implied rather than stored. If the discount is folded into the taxable value, the accountant cannot see the pre-discount figure. If the tax is stored only as a document total, the line tax is unrecoverable. If a credit note does not point at the document it reverses, the netting has to be done by matching on amount, and matching on amount is a guess whenever two documents share one.
Illustrative: a document stored as a total versus a document stored as values that add up
| Question at quarter-end | Total-only record | Value-level record |
|---|---|---|
| What was the taxable value of the invoice? | Available, but only as a figure the system derived | Available as a stored sum of line taxable values, with the lines underneath |
| What tax was recorded on each line? | Not recoverable; only the document tax total exists | Stored per line, and sums to the document tax total by construction |
| Was a discount applied, and where? | Only by comparing the total against a recomputed price list | Stored as its own value with the basis it was applied to |
| What does the document net to after credit notes? | Requires matching credit notes to the document by amount and date | Credit notes reference the document they reverse, so the net is a sum |
| Is anything outstanding? | Requires reconstructing payment history by hand | A projection of allocations against the document, recomputed from payment records |
A worked example, constructed so you can check the arithmetic
Every figure below is constructed for this article. There is no real customer, no real invoice, and no real compliance outcome behind any of it, and nothing here is a statement about what any document must contain. The 18% rate is used, and only used, so that each line of the arithmetic can be checked by hand in a few seconds. It is a prop for arithmetic, not a claim about any slab or classification.
Start with an invoice carrying two lines. Line one has a taxable value of Rs 8,000. Line two has a taxable value of Rs 4,500. The document taxable value is 8,000 plus 4,500, which is Rs 12,500.
Tax at 18% is 8,000 multiplied by 0.18, which is Rs 1,440, on the first line, and 4,500 multiplied by 0.18, which is Rs 810, on the second. The document tax is 1,440 plus 810, which is Rs 2,250. Check it a second way: 12,500 multiplied by 0.18 is 2,250.
The document total is the taxable value plus the tax, so 12,500 plus 2,250 is Rs 14,750. Check it a third way: 12,500 multiplied by 1.18 is 14,750. Three routes, one answer. If your system can only produce one of those three, the other two are being reconstructed by a person.
Now apply a discount of Rs 500 to the taxable value, before tax. The discounted taxable value is 12,500 minus 500, which is Rs 12,000. The tax is now 12,000 multiplied by 0.18, which is Rs 2,160, which is 90 less than before, and 90 is 500 multiplied by 0.18. The total is 12,000 plus 2,160, which is Rs 14,160. The saving to the customer is 14,750 minus 14,160, which is Rs 590, and 590 is 500 multiplied by 1.18. The discount is visible as its own number, which is what makes the difference between 14,750 and 14,160 explicable rather than mysterious.
Now a credit note reversing line two in full. Its taxable value is Rs 4,500, its tax is Rs 810, and its total is Rs 5,310, which is the exact negation of the line. Netting it against the invoice: the taxable value is 12,000 minus 4,500, which is Rs 7,500; the tax is 2,160 minus 810, which is Rs 1,350; the total is 14,160 minus 5,310, which is Rs 8,850. Check: 7,500 multiplied by 1.18 is 8,850.
Finally a payment. A customer pays Rs 5,000 in cash against the invoice. The invoice and the payment are different records. The payment is not an attribute of the invoice; it is a separate document that has been allocated against the invoice. The allocation is a link, and the amount outstanding is the invoice net of the credit note, 8,850, less the allocation, 5,000, which is Rs 3,850. Nothing in the invoice says it is unpaid, and nothing in the invoice says it is paid. The system reports one or the other by computing the projection from the allocations, which is why the projection can change when a payment is re-allocated and why an invoice document is a stable record while a status is not.
What the underlying records have to make possible
If an accountant is to re-add your quarter without trusting you, five things must be true of the records rather than of the software. These are record properties, and they are testable in an afternoon with a pencil.
Every line carries a taxable value and a tax amount as two separate stored values, so the relationship between them can be checked rather than believed. Every line carries the rate that was applied, so a check does not require a rate table lookup. Every discount is stored as a value with the basis it applied to, so a total that does not match a recomputed price list has an explanation available. Every credit note points at the document it reverses, so netting is a sum and not a guess. And every payment is a separate record with an allocation, so outstanding is a derivation and not a field somebody typed.
The property that ties all five together is that a person can re-perform them. Not trust them, not read them, re-perform them. A system whose figures can only be verified by exporting them and recalculating in a spreadsheet has outsourced the verification, and your accountant will do it anyway, by hand, without your help.
A pencil test you can run on any system in one afternoon
- Pick three invoices from the quarter, including one with a discount and one with a credit note against it.
- For each, add up the line taxable values by hand and compare with the document taxable value. They must match exactly.
- Multiply each line taxable value by the rate printed on that line and compare with the line tax. Any difference is a rounding convention you should be able to name.
- Add up the line tax amounts and compare with the document tax. Then add taxable plus tax and compare with the total.
- For the discounted invoice, confirm the discount appears as its own value and that the taxable value it applied to is visible.
- For the credited invoice, confirm the credit note references it, and that the credit note figures are the exact negation of what was reversed.
- For the payment, confirm the payment is a separate record with an allocation, and that outstanding is computed from that allocation rather than stored on the invoice.
- Finally, confirm you can produce the same figures in an export without re-keying anything, and that a colleague can re-perform the whole check without asking you a question.
What the software does not produce, and should not be expected to
The list of things a quarter-end needs that a counter billing system does not produce is not a defect list. It is a description of two different categories of work, and knowing which is which saves a great deal of money and a good deal of argument.
NoxOrigin does not file GST returns, does not generate or submit returns, is not a tax authority, and is not certified. It has no return preparation, no e-invoicing submission, no e-way bill generation, no TDS or TCS recording, no reverse-charge handling, and no place-of-supply engine. If your quarter-end includes producing a statutory return or transmitting a document to a government system, that is work for a different category of software, and it is work your chartered accountant does with their own tooling.
What a counter billing system does produce is the clean source material that such work consumes: line-level taxable values and tax, discounts with their basis, credit notes linked to what they reverse, payments with their allocations, stock movements tied to the sale, and a day-end picture of a trading day. The product page is honest about the whole capability list, including the modules that are assisted-setup maturity rather than switches.
Two maturity items deserve a specific mention here, because quarter-end is exactly where people assume they are self-serve. Shift close and day-end reconciliation are assisted-setup maturity, not self-serve switches. That means they are configured with you during setup rather than switched on in an afternoon, and it means the
What the software does not produce is the answer. Even a quarter in which every record above is perfect produces a set of figures, not a position. Deciding what those figures mean, what follows from them, and what has to be filed is the chartered accountant's work, and the honest way to describe the relationship is that your system hands over arithmetic they can verify, and they hand back a position you can act on.
Illustrative: the handoff, split by who is responsible for what
Your system produces
Line-level taxable values, tax amounts and rates. Discounts with their basis. Credit notes referencing the document reversed. Payments as separate records with allocations. Day-end and shift-close figures once the assisted setup has been done. Exports a person can re-add without re-keying.
Your chartered accountant produces
Every statutory position. Return preparation and submission. Treatment determinations, place-of-supply conclusions, and reverse-charge questions. The meaning of a quarter's figures and what follows from them. NoxOrigin is not a tax authority and is not certified.
If the handoff is what you are shopping for, the useful comparisons are our note on billing software versus accounting software, which sets out the division of labour between the two categories, and the guide to what a billing platform for accountants should provide so the handoff does not need re-keying. For the day-end side, the practical closing routine and the UPI reconciliation routine are the two pieces most businesses need before a quarter-end is quiet rather than busy. For the document itself, the GST invoice field checklist is the reference for testing a system against a document. For the buying decision overall, see how to choose GST billing software for a small business in India.
None of these replace your own chartered accountant, and none is a substitute for the arithmetic in the section above, which you should run yourself on your own documents.
The one-line version. A quarter-end reconciliation is a small number of sums over a set of documents. It survives only if the records hold line taxable values, line tax amounts, the rate applied, discounts with their basis, credit notes pointing at what they reverse, and payments as separate records with allocations. If your accountant has to re-key to check your figures, the system is storing conclusions instead of values. What the figures mean is your chartered accountant's determination. NoxOrigin does not file GST returns, does not generate or submit returns, is not a tax authority, and is not certified.
Frequently asked questions
What has to be true for my accountant to re-add the quarter by hand?
Five things: line taxable values and line tax amounts stored as separate values, the rate applied recorded per line, discounts stored as their own value with the basis they applied to, credit notes that reference the document they reverse, and payments held as separate records with allocations. Together they let a person re-perform the arithmetic rather than trust it.
Is an invoice paid or unpaid?
Neither, as a stored fact. Invoice and payment are different records. Paid and outstanding are projections computed from allocations against the invoice, which is why a re-allocation can change the projection without changing the invoice. Any figure described as collected or outstanding has to be stated together with the allocations behind it.
Can NoxOrigin produce my GST returns for quarter-end?
No. NoxOrigin does not file GST returns, does not generate or submit returns, is not a tax authority, and is not certified. There is no return preparation, no e-invoicing submission, no e-way bill generation, no TDS or TCS recording, and no reverse-charge handling. Your chartered accountant does that work with their own tooling.
Is shift close and day-end reconciliation a switch I can turn on?
No. Shift close and day-end reconciliation are assisted-setup maturity rather than self-serve switches, which means they are configured with you during setup. A quarter-end that depends on day-end figures depends on those sessions having happened, so plan for them rather than assuming they will be waiting.
What does the system actually hand over at quarter-end?
Line-level taxable values, tax amounts and rates, discounts with their basis, credit notes linked to what they reverse, payments with their allocations, stock movements tied to the sale, and day-end figures, in exports a person can work from without re-keying. The figures are the deliverable. The position they add up to is your chartered accountant's determination.