The Approval Nobody Knew They Needed
An exception taken by a good employee who had no idea an approval was required. Why a written rule nobody has read is not a control, who should hold the exception list, and what happens when the approver is on leave.
Somebody approved nothing, broke nothing, and still created a problem. They applied a discount that policy says needs a sign-off, waived a credit limit, cancelled an invoice, or released stock at a price nobody sanctioned. Every one of those actions is normal. Every one of them was, on that day, the fastest reasonable thing to do. And every one of them should have had a name attached to a decision, and none of them do. The gap between the action and the trace is where the trouble lives.
The uncomfortable part of this failure mode is that it usually happens to a good employee. This is not a story about someone cutting a corner because they did not care. It is a story about a policy that exists in a document nobody has opened, an exception list that lives in one person's head or one person's inbox, and an approval step that was designed for a business of a different size and never re-examined. The person did the right thing as far as they knew. What they could not do was record a decision they did not know they were making.
A rule nobody has read is not a control
An approval rule is a sentence in a policy document. It works only if the person who is about to trigger it knows it exists, knows what threshold they have just crossed, and knows who can say yes. Those are three separate things, and a written policy usually only supplies the first. The other two live in habit, in onboarding, and in the assumption that a rule is self-evident to anyone who works there. For a business of four people that assumption sometimes holds. It fails first with new staff, and it fails hardest when the business grows and the person who used to personally handle every exception is now on a plane.
So the first question is not "do we have a policy" but "does the person at the counter know the threshold without having to ask". If the honest answer is that they would have to ask, the policy is a piece of internal communication that has not been delivered, and no audit will tell you that.
The exception with no name on it
Here is a constructed example. The figures are invented and the arithmetic is shown so you can check it. A distribution business allows sales up to a credit limit of ₹50,000 per customer without a second signature, and requires a signature above that. In one month, four overrides are recorded. The person applying them believes there is no limit, because the limit was communicated verbally when they joined and never appeared on the screen they work from.
Illustrative: four overrides in a month against a ₹50,000 limit (constructed example)
| Order | Amount | Who applied it | Approval trace on the record |
|---|---|---|---|
| 8 June | ₹8,000 | Sales executive | None — the order was under the limit the executive believed existed |
| 17 June | ₹15,000 | Sales executive | None — a phone call to the owner, not recorded anywhere |
| 24 June | ₹22,000 | Night-shift executive | None — the only order above the limit, and no deputy had been named |
| 29 June | ₹9,000 | Sales executive | None |
Worked example, constructed for this article — the arithmetic.
Override amounts in the month: 8,000 + 15,000 + 22,000 + 9,000 = ₹54,000
Which means the month's overrides are ₹54,000 against a policy limit of ₹50,000, so they exceed the limit as a group by:
- 54,000 − 50,000 = ₹4,000
A limit applied per order would have flagged exactly one of the four — the ₹22,000 on 24 June is the only single order above ₹50,000. That is a common and unpleasant surprise: a policy written as "above ₹50,000" is not the same rule as a policy written as "when this month's orders total more than ₹50,000". The first is a single-order test, the second is a running-total test, and a person working from memory will apply whichever one they happen to imagine.
The 24 June order is also the one that happened at night, when the person who could have said yes was not reachable. One order out of four, and the one that went unapproved is the one taken at the moment nobody could be asked.
Discounts are the quiet ones
Overrides are dramatic and get discussed. Discounts are quiet, which is why they are usually where the real money leaks. A policy says discounts above a given percentage need a second signature. An invoice is raised at a discount that crosses it. The person applying the discount is not cheating — they are doing exactly what a good salesperson does on a Friday — and the record looks completely normal to anyone who has not read the policy.
Worked example, constructed for this article — the arithmetic.
Invoice IN-311, base value ₹42,000, discount applied 12%, policy requires a second signature above 10%.
- Discount: 42,000 × 0.12 = ₹5,040
- Net taxable value: 42,000 − 5,040 = ₹36,960
- GST at 18% of the net value: 36,960 × 0.18 = ₹6,652.80
- Invoice total: 36,960 + 6,652.80 = ₹43,612.80
What the record shows by itself: a correct invoice with a 12% discount and a named employee. Nothing in the invoice says an approval was required. The gap between ₹5,040 and a 10% discount is:
- 10% of 42,000 = ₹4,200
- 5,040 − 4,200 = ₹840 of discount above the threshold
The 18% GST figure again exists only so the totals can be checked by hand. Whether a rate, an invoice, or a discount treatment is right for your business is a question for your own chartered accountant.
₹840 is not a large number, and that is the argument. The value of catching the approval gap is not the value of this one discount. It is that the same uninformed person will do it again, and the pattern is invisible until someone reconstructs it. The trigger for the conversation should be the pattern, not the amount.
Who holds the list, and what happens on leave
Every mature business has a short list of exceptions that need a second person. It is usually four to eight lines: above this credit limit, above this discount, below this margin, over this age of account, refunds above this amount, cash discounts over a limit. Two things are true of that list almost everywhere. First, it usually exists in a policy document, a spreadsheet, or the head of one person — and those are three different places to look, which means it is three different places to forget. Second, it has exactly one approver on most days, which is the quiet failure point of any control with a single point of contact.
Illustrative: where an exception list can live, and what each location can prove
| Where the list lives | What it can prove | What it cannot prove |
|---|---|---|
| A policy document in a shared folder | That a rule was written down, and when it was last edited | That anyone has read it, understood it, or was told it applies to them |
| The head of one person | Whatever that person remembers, in the order they remember it | That the rule was applied the same way twice, or that it was ever stated |
| Permission and threshold settings in the system | Which roles were allowed to do what, on which date, and who did it | That the person knew a threshold existed before they crossed it |
| A chat thread where it was discussed | That a decision was made on a date by identifiable people | Which transactions the decision actually covers |
The approver is on leave
A control with one approver is not a control, it is a bottleneck with a title. The question to ask is not "who approves" but "who approves when the approver is unreachable, and is that person the same person who would have approved it". Three workable answers exist and all three are better than the status quo. Name a deputy for each exception category. Or set the threshold in the system so that a below-threshold action does not need anyone at all, and reserve the human signature for genuinely large decisions. Or accept that below a certain amount the exception is a decision, not an approval, and say so out loud so nobody is inventing a rule at eleven at night.
Worked example, constructed for this article — the arithmetic.
A later month, the same ₹50,000 limit, and the single approver takes six working days off. Three exceptions are taken in that window:
- 7,500 + 11,500 + 13,000 = ₹32,000
Every one of the three is below ₹50,000 on its own, so a per-order threshold flags none of them. The total exposure taken without any signature during six working days is ₹32,000 — and nobody was in a position to object to any of the three, because there was no one to object to and no deputy named. Once the approver returns, the reconstruction is possible only if the individual actions carry a name and a time, which they do when the action happens inside the system and do not when the exception was a verbal override at a counter or a discount typed into an invoice by someone who did not know a threshold existed.
A useful check: six working days is roughly 6 of the 26 working days in a month, so close to a quarter of the month ran with no approver reachable. A control that fails on the days it is most inconvenient is not a control, and the cost of it here is not the ₹32,000 — it is that three of the month's decisions have no second name attached to them at all.
Why an approval with no trace cannot be audited
An audit is a question about the past asked by someone who was not there. The only thing that can answer it is a record made at the time, by a person, with a name. "I think I spoke to him on WhatsApp" is not an audit trail; it is a reconstruction offered years later, from memory, by someone who has an interest in the answer. "Invoice IN-311 was created on 14 June at 16:42 by the night-shift login, with a 12% discount, under a role that did not require a second signature" is a fact. One of them survives a hostile question. The other does not.
The practical consequence is unglamorous. If you cannot produce who did what, then the only available explanations are that the controls failed or that the records were never good enough to tell. Businesses pick the first one, because the second one is unacceptable and also because the second one is unprovable. That is worth a great deal to somebody one day, and it is entirely free to avoid by making the trace part of the action rather than a report you run afterwards.
A control that survives a hostile question
What to put in place, in this order
- Write the exception list as a list of thresholds with numbers in it. A rule without a number is a sentiment, and sentiments cannot be enforced.
- For each threshold, decide the mechanism: blocked by permission, allowed but flagged, or allowed and silently fine. Choose deliberately per line — a system where everything is blocked teaches people to work around it.
- Name a deputy for every threshold. One approver plus a holiday is a control that fails on a schedule.
- Put the threshold where the decision happens, not in a document near it. A person about to type a discount should not have to remember a rule to know whether they may.
- Decide what happens to exceptions taken while the approver was unreachable. Backfilling an approval afterwards is a different act from approving in the moment, and the record should not pretend they are the same.
- Review the list on a fixed date, not on an incident. A quarterly half-hour with the numbers in front of you catches the pattern; a post-mortem catches one instance.
One last thing, because it is the part people skip. The person who applied the uninformed discount is not the problem, and treating them as the problem makes the next exception harder to see. In every constructed example above, the action was reasonable given what that person knew. The fix is to move the knowledge, not to move the blame. Roles, thresholds, and a named trail are the mechanism for moving knowledge; a conversation is the mechanism for moving blame, and only one of them changes what happens on the next Friday.
The same drift shows up as a missing rule, a missing permission, and a missing scope. the permission nobody asked for the process nobody wrote down the scope nobody wrote down the process everyone bypasses
Frequently asked questions
Does NoxOrigin have an approval-request record with a pending and approved status?
No. There is no generic request-and-response object. What exists is role-based permissions so a person can only perform the actions their role allows, thresholds on actions that need them, and a per-user activity trail. If your process needs a formal pending approval queue, that is a different kind of tool.
If a discount was taken without an approval, can NoxOrigin tell me who took it?
It can tell you which user account recorded the action and when, because the action carries a name and a timestamp. It cannot tell you whether that person knew a threshold existed — that knowledge is not a record. Which is precisely the point: the audit trail gives you the fact, and moving the threshold onto the screen gives you the knowledge.
How should I handle exceptions taken while the approver was on leave?
Decide the policy before it happens, and pick one: a named deputy, a lower threshold that does not need a signature, or an explicit statement that small exceptions are decisions rather than approvals. Whatever you pick, record the exception as a backfill so a later reader can tell it apart from a real-time approval.
Are expenses and approvals handled in the unified NoxOrigin app?
Expenses are a Nox-Billings capability, and purchasing lives in Commerce. The unified app is not a full expense or payroll system, it has no timesheet record, and it does not file GST returns. The current availability and maturity of each area is listed on the product status page.