The Branch That Closes Its Books Differently
A permission difference, a discount rule set locally, a day-end done a day late. Why a business-wide policy is not a business-wide outcome, and what comparing sites on their own numbers can and cannot tell you.
Every multi-site business has a written policy. Discounts above a threshold need approval. Every day closes at the end of trading. Prices are the same everywhere because the owner said so. The policy is real, the owner means it, and it is usually in a document somewhere.
Then a site opens at 09:00 with a counter that a different person runs, and the permissions are not quite the same, and the discount that needs approval gets given anyway by someone who can approve it, and the day-end gets done at 09:15 the next morning because that is when the person who does it arrives. Nothing was ignored. The policy was simply interpreted, locally, by a competent person, in a way that is defensible from inside that site and indefensible from outside it.
This is the article about the gap between a business-wide policy and a business-wide outcome. The gap is not a failure of the policy. The gap is that a policy is a sentence and an outcome is a number, and the sentence has to survive contact with eleven different people before it becomes a number.
A constructed exampleThe discount example: a permission difference wearing a performance costume
Here is a worked example we constructed for this article. The two sites, the figures, and the permissions are invented so that you can check the arithmetic by hand. The 18% GST rate appears only to keep the totals checkable and is not guidance on how anything should be treated.
Both branches sell the same ten items on the same day to the same kind of customer. List price is ₹1,000 taxable per item. At Branch A, the cashier may apply a discount of up to 5% without approval, and applies 5% to all ten sales. Branch B has no cashier discount permission at all; a manager must approve, and in practice the manager approves and applies the same 5%.
Branch A: ₹1,000 − 5% of ₹1,000 = ₹1,000 − ₹50 = ₹950 taxable per item. GST at 18% is ₹950 × 0.18 = ₹171, so gross is ₹950 + ₹171 = ₹1,121 per item. Ten items is ₹1,121 × 10 = ₹11,210. Branch B, having had exactly the same 5% applied by a different person with a different permission, records ₹1,000 taxable per item, GST of ₹180, gross of ₹1,180 per item, and ₹1,180 × 10 = ₹11,800.
The owner looks at the two numbers. Branch A recorded ₹11,210 and Branch B recorded ₹11,800. Branch A appears to have a problem worth ₹11,800 − ₹11,210 = ₹590 for the day. The owner has found a branch that is underperforming, and is about to have a conversation with a manager about effort.
The ₹590 is exactly ₹50 × 1.18, repeated ten times, and it is a permissions difference. The two sites sold the same items, to the same customers, at the same discount, on the same day. One of them recorded the discount where the cashier was permitted to record it and the other recorded it where a manager had to approve it first. The number is not measuring performance. The number is measuring where in the approval chain the discount was typed.
There is a worse version of this, which is where the discount was not authorised anywhere and the difference is not 5%. We are not going to print a rate for it, because the reader is already converting it into a benchmark, and it is one invented day.
Three ways a site drifts without anybody deciding to drift
Illustrative: the three common local differences, and the record that settles each
A permission is set locally
One site can discount, cancel, or reopen and the other cannot. The site with the extra permission produces a different revenue and a different cancellation count for the same behaviour. Settle it with the permission record, not with the revenue.
A rule is written locally
A rounding convention, a price list maintained by hand, a discount band that lives in one manager's head and gets applied consistently. The site is not disobeying anything, because there is nothing written to disobey. Settle it by writing the rule down once and applying it at both sites.
The work is done late
The day-end happens the next morning, so variances and corrections land on the wrong calendar day. The total for the month is unaffected. The daily series is affected, and a report that compares days across sites will disagree for a reason that has nothing to do with the trading.
The day-end done a day late, and why the month still balances
The timing case is worth working through because it looks alarming and is not, which is exactly why it survives.
Branch A expects cash of ₹42,000 on 10 April and counts ₹41,850. The variance is ₹41,850 − ₹42,000 = −₹150. Branch A does its day-end on the evening of the 10th, so the variance is recorded against 10 April. Branch B has the identical expected cash and the identical counted cash and the identical −₹150 variance, but does its
Now build the daily series. Branch A shows −₹150 on the 10th and zero on the 11th. Branch B shows zero on the 10th and −₹150 on the 11th. The consolidated daily series shows −₹150 on the 10th and −₹150 on the 11th. The per-site daily series, added up by a person with a calculator, shows −₹150 on the 10th and −₹150 on the 11th as well, because the two zeros and the two −₹150s line up in total.
The month agrees. The days do not. The month total for the two sites is −₹300 either way, which is why this never becomes an emergency and why it can survive for years. What breaks is any comparison that is about a day rather than a month: a variance review on the 10th, a cash-position report on the 10th, a count of how many days had a variance, a conversation about which branch has a cash problem. All of those are wrong, and all of them are wrong because of a nine-hour difference in when a person arrived at work.
This is also why a variance figure needs a date and an owner rather than just an amount. A variance attached to 10 April is a fact about 10 April. A variance attached to 11 April, because that is when the close was run, is a fact about the close. Confusing the two is what makes a small operational difference look like a pattern.
The rounding case, for completeness.
Suppose the taxable value on a line is ₹333.33 and the agreed discount is 10%.
- Discount per line: 10% of ₹333.33 = ₹33.333, so the line is ₹333.33 − ₹33.333 = ₹299.997.
- Three such lines, rounded per line: ₹299.997 rounds to ₹300.00 each, so ₹900.00.
- Three such lines, rounded once on the invoice: 3 × ₹333.33 = ₹999.99, less 10% of ₹999.99 = ₹99.999, giving ₹999.99 − ₹99.999 = ₹899.991, which rounds to ₹899.99.
The difference is ₹900.00 − ₹899.99 = ₹0.01. Do not spend an hour on the paise. The point of this example is not the amount. It is that the two sites now have different rounding rules, and a rule nobody wrote down is a rule that will be changed by whoever is on shift.
What comparing two sites on their own numbers can and cannot tell you
This is the most useful part of the article, because a branch comparison is a reasonable thing to want and an unreasonable thing to do without this distinction in mind.
Illustrative: a branch comparison can support these, and cannot settle these
It can tell you the sites are behaving differently
If two sites run the same products at the same prices and one consistently records less revenue, something differs. The comparison has found a difference. It has not found a cause, and it has not found a fault.
It can tell you a site is not following a written rule
Where the rule is written down, the comparison is evidence. A site applying a discount the written policy does not permit is a site that is not following the policy, and that is a conclusion the numbers support.
It cannot tell you which site is more profitable
Expenses are recorded in Nox-Billings, and the unified record is not a full expense, payroll, or accounting system. A revenue comparison is not a profit comparison, and the gap between those two sentences is where most branch arguments go wrong.
It cannot tell you whether a difference is demand, price, or permission
Those three produce identical-looking revenue lines. Separating them requires the permission record, the price list, and the day-end timestamps, not a ratio computed from two totals. Where a ratio would be the obvious number to print, we decline to print it, because it would look like a benchmark we have measured and we have not.
What to do about a site that has quietly become its own system
Illustrative: making the policy and the outcome the same thing
- List the permissions that exist at each site, side by side, rather than the permissions you intended. The gap between the two lists is the whole subject of this article, and it is usually longer than anyone expects.
- Decide which permissions genuinely differ by design, for example a warehouse that cannot issue a customer invoice, and write down the ones that are meant to be identical. The intended list is the one that was never written.
- For every local rule, decide whether it becomes a business-wide rule. Rounding, price lists, discount bands, and the day-end time all belong in one place, and the person who maintains that place is named.
- Move the day-end to a named time at each site, and make a variance land on the trading day it belongs to rather than the day the close was run. This one change removes most of the phantom day-level differences.
- Compare sites on taxable value, tax, and gross as three separate columns, and on a single stated definition of each. Never compare a blended figure at one site against a blended figure at another.
- Decide who may reopen a closed day, at each site, and record it. A site that can reopen yesterday and a site that cannot are two different systems wearing the same policy document.
- When you find a difference, ask which of the three causes it is before you ask who is responsible. Demand, price policy, and permission all look the same in the revenue line and only one of them is anybody's fault.
- Repeat the comparison at the end of the next period without changing anything. Differences that do not move were never performance, and treating them as performance is the expensive part.
Where this stops, plainly
Permissions and their audit history are the part of NoxOrigin that addresses this directly. Workspace-scoped roles across branches, teams, people, roles, and devices, with recorded activity, are described on the [role-based access page](/role-based-access-business-software), and what a permission system is and is not is covered in [anatomy of a permissions system](/blog/anatomy-of-a-permissions-system). Permissions are only half the problem though. A permission that is correctly configured and a policy that is actually followed are two separate achievements, and the second one is a management practice rather than a configuration.
Shift close and day-end reconciliation are assisted-setup maturity rather than self-serve switches, and this is the second article in this cluster to say so plainly, because a branch comparison page is exactly where a reader assumes the tool will enforce a close on its own. It will not. It will give both sites the same sequence, the same variance handling, and the same review step, configured with help, and then it will show you what each site actually did. A site that runs its close at 09:15 the next morning will still be doing that, and the report will still be showing you the difference, and that is the honest outcome.
There is also a limit worth naming: NoxOrigin has no timesheet record and no payroll module, and expenses live in Nox-Billings only. So when a branch's revenue is lower than another's, the system cannot tell you whether that branch had fewer staff on the counter that day, and a revenue-per-person comparison is not available from these records. If that comparison matters to you, it has to be assembled from your own staffing data alongside the billing numbers, and no report in NoxOrigin will assemble it for you.
Nor is any of this tax or compliance advice. If a difference in gross between two sites raises a question about what should be reported or how, that question goes to your own chartered accountant, and it is precisely the kind of question where a generic article is at its least reliable.
Frequently asked questions
One branch consistently records less revenue than the other. What does that tell me?
It tells you the two sites are behaving differently, which is real. It does not tell you the cause or the fault. Lower revenue at a site can be weaker demand, a different authorised price, a different permission, or a day-end running on a different clock, and those four produce identical revenue lines. Start with the permission list, the price list, and the day-end timestamps rather than with a ratio.
Our branches have different discount permissions on purpose. Is that a problem?
Not by itself. A deliberate difference is fine, and a warehouse that cannot invoice a customer is a sensible design. The problem is a difference nobody wrote down, because the owner reads the policy document and the report as two statements of the same thing, and they are not. Write down which permissions differ by design and make the rest identical.
Our day-end runs the next morning. Does that break monthly reporting?
Usually not the month. In the worked example here, the month total agrees to the rupee while the daily series does not, which is why the problem survives for years. What breaks is anything that reads a day rather than a month: variance reviews, cash positions, and counts of days with a variance. Getting the variance onto the trading day it belongs to removes most of it.
Can I compare profitability between two branches?
Not from these records alone. Expenses are recorded in Nox-Billings, and the unified record is not a full expense, payroll, or accounting system. There is no timesheet record and no payroll module, so a revenue-per-person comparison is not something the system can produce. A revenue comparison is available; a margin comparison has to be assembled from your own cost data.
Does NoxOrigin enforce a consistent close across both branches automatically?
No, and we would rather say it here than have you discover it. Shift close and day-end reconciliation are assisted-setup maturity, not self-serve switches. The sequence, the cut-off, the variance handling, and the review step are configured with help, and afterwards the system reports what each site did rather than forcing it.
Sources and further reading
- NoxOrigin: role-based access — workspace-scoped permissions across branches, teams, people, and devices
- NoxOrigin: day-end reporting — shifts, payment mix, expected cash, counted cash, variance, and exceptions
- NoxOrigin: expense tracking in Nox-Billings, and what the unified app does not cover
- Institute of Chartered Accountants of India