Two Branches, Two Sets of Numbers: Why a Consolidated Total Can Be Wrong

Here is a worked example we constructed for this article. The branches, the amounts, and the close times are invented so that you can check the arithmetic by hand. The 18% GST rate appears in this article only to keep the totals checkable; it is not offered as guidance on how anything should be treated.

Branch A and Branch B both sell on 1 April. Branch A closes its business day at 21:00. Branch B closes its business day at 23:00. On 1 April, Branch A records taxable sales of ₹1,18,000 and Branch B records taxable sales of ₹96,000. GST at 18% on Branch A is ₹1,18,000 × 0.18 = ₹21,240, so Branch A's gross for the day is ₹1,18,000 + ₹21,240 = ₹1,39,240. GST on Branch B is ₹96,000 × 0.18 = ₹17,280, so Branch B's gross is ₹96,000 + ₹17,280 = ₹1,13,280. The owner adds them: ₹1,39,240 + ₹1,13,280 = ₹2,52,520, and labels it 1 April sales for the business.

That number is wrong, and there is no way to tell from the report that it is wrong. In this example, Branch A's close on 1 April actually finished at 20:45, because the person who does the close was late. The last sale of the day was stamped 20:44 and carries taxable value of ₹14,000. Read against Branch A's intended 21:00 cut-off, that sale belongs to 1 April. Read against what actually happened, it belongs to 31 March.

So the honest figure for 1 April is Branch A at ₹1,18,000 − ₹14,000 = ₹1,04,000 taxable, and Branch B at ₹96,000 taxable. Taxable for the day is ₹1,04,000 + ₹96,000 = ₹2,00,000. GST is ₹2,00,000 × 0.18 = ₹36,000. Gross is ₹2,00,000 + ₹36,000 = ₹2,36,000. The naive total was ₹2,52,520. The difference is ₹2,52,520 − ₹2,36,000 = ₹16,520, and that is exactly ₹14,000 × 1.18. The whole discrepancy is one sale at one site, and it is only visible once somebody states that the cut-off was missed.

You will notice we did not print the percentage this represents. A reader is tempted to divide ₹16,520 by ₹2,52,520 and get a figure that looks like a finding. It is not a finding. It is one transaction we invented, and printing it as a rate would invite every reader to compare their own two sites against a number that describes nothing outside this article.

The sales figure is the number people argue about. The collection figure is the number that quietly disagrees, and it disagrees for a completely different reason.

In Nox-Billings an invoice and a payment are different records. There is no stored paid flag on an invoice that somebody ticks. What a system shows as paid is a projection of allocations: payments that exist, allocated against invoices, net of what has already been allocated elsewhere. That distinction is the reason the same payment can be counted two ways at two sites without either site being wrong.

Extend the constructed example. One customer pays ₹50,000 against an invoice raised at Branch A. Branch A records the payment on 2 April. Branch B, for reasons of its own habit or its own cut-off, records the same ₹50,000 on 1 April. The money arrived once. The bank balance at the end of the month is identical either way. But Branch A's April collections are ₹50,000 lower than Branch B's April collections, and the business-wide collected-in-April figure is either ₹50,000 too high or ₹50,000 too low depending on which branch the report happens to read as the source of truth.

This is not a rounding difference. ₹50,000 is not a rounding difference. It is a fact about when a record was made, being read as a fact about when money moved, at two sites that were each being technically correct in their own frame.

Consolidation is not a reporting feature. It is an agreement, and the agreement has to exist before the report is trustworthy. The table below is illustrative: it is a shape we have found useful, not a standard, and your own answer for each row may legitimately be different. What matters is that both branches give the same answer, in writing, and that the answer is written somewhere a person can read in three months.

It is tempting to describe a multi-location setup as: connect both branches, tick consolidate, read the total. That sequence puts the easy operation in front of the hard one. The easy operation is arithmetic. The hard one is agreeing what is being measured, and it does not have a tick box.

There is also a structural reason the agreement has to come first. Once a consolidated report exists, it becomes the number people manage to. Individual branch numbers become a diagnostic detail, looked at only when the consolidated one surprises somebody. But the branch numbers are where the disagreement is visible. They differ from each other for a reason, and the reason is usually a fact about the operating rules rather than a mistake in arithmetic. If you go straight to the total, you have thrown away the evidence and kept the conclusion.

There is a second, more practical reason. Almost every question about a consolidated figure decomposes into a branch-level question. Which branch caused the variance? Which branch stamped this sale on the wrong day? Which branch recorded the payment a day early? Once a total is the primary artefact, all of these questions begin with a disaggregation that the report may not support, and you are back to the two numbers with less context than you started with.

So the practical order is: settle the six questions, run both sites the same way for a full closed period, compare the branch figures against each other, and only then add. The addition should be the boring, unremarkable last step. If the addition is the interesting step, the agreement did not happen.

The order matters more than the effort. Doing the comparison first and the consolidation later means the first month produces a real answer, not a total that has to be unpicked in the second month.

It is worth being plain about the limits, because a multi-location page is exactly where a reader assumes a self-serve multi-site close.

Shift close and day-end reconciliation in NoxOrigin are assisted-setup maturity rather than self-serve switches. That means the sequence, the cut-off, the variance handling, and the review step are configured with help rather than being something a branch manager enables alone at 9pm. A business that assumes it can turn on a clean multi-site close in an afternoon is going to discover the difference at the end of its first month, and it is easier to arrange the setup deliberately than to unpick a month of half-closed days.

Consolidation also does not reconcile anything on its own. It presents the records that already exist, in one view, on the basis you have agreed. If the two branches were closing differently before you connected them, connecting them will not make them close the same afterwards. It will simply show you both, side by side, forever.

And a consolidated total is not an accounting result. This article does not tell you how a multi-site business should present anything on a return, and it does not tell you whether a movement between two branches of your business is a supply in the sense the law means. Both of those are questions for your own chartered accountant, and both of them are exactly the questions where a generic article is at its least reliable.

Once both branches close the same way, the multi-location closing review becomes an ordinary review rather than an investigation. Periods, payment totals, transfers, variances, and exceptions are compared across sites on a basis everybody agrees on, and the exceptions that surface are real ones rather than artefacts of two different close times.

That review has its own failure modes, and one of them is the exception that everybody has learned to accept because it appears every month at the same site. We wrote about the shape of that review separately, including how to tell a genuine recurring exception from a close that is merely done differently, and it is worth reading before you build the routine rather than after. The [multi-location closing and exception review](/blog/the-branch-that-closes-its-books-differently) covers the review itself; this article is about whether the numbers arriving at that review were ever comparable.

The companion failure modes in this cluster are worth reading in the same sitting, because they are the same problem in a different room. A stock movement that one site recorded and the other never heard of is covered in [the transfer between branches that never arrived](/blog/the-transfer-between-branches-that-never-arrived). A site that closes its books by different rules is covered in [the branch that closes its books differently](/blog/the-branch-that-closes-its-books-differently). And whether a second location should be in the same system at all is covered in [when two locations are really two businesses](/blog/when-two-locations-are-really-two-businesses). What two people need before they compare one number with another is covered in [what a number needs before two people compare it](/blog/what-a-number-needs-before-two-people-compare-it), and whose day a timestamp belongs to is covered in [whose hour is it, shifts and the business day](/blog/whose-hour-is-it-shifts-and-the-business-day).