The Dropdown That Posts Revenue
A storekeeper releasing material picks a reason from a list. Two of the reasons on that list post revenue and cash to your ledger at the item's selling price, with no customer, no invoice and no tax — and nothing in the label they read says which two.
Every stock issue requires a reason, and requiring one is good practice that most systems get right. What is less widely understood — including, for a while, by us — is that the reason is not a note. It is a switch on the accounting, and it lives on a dropdown operated by whoever happens to be standing at the store window at four in the afternoon.
This article is about a mechanism that is genuinely useful and genuinely dangerous in the same breath. Nothing described here is a defect. All of it is behaviour you should know about before you write your reason list, because the reason list is a chart-of-accounts decision disguised as a data-entry convenience.
What a reason carries
A reason has a name, a description, and one flag: whether it generates revenue. That flag is the entire mechanism, and it does what it says.
On an ordinary issue, approving it posts a single entry per item: expenses debited, inventory assets credited, at the item's buying price. Stock leaves, cost is recognised, and that is correct.
On an issue whose reason is flagged as revenue-generating, that entry is posted and then a second one is: cash debited, sales revenue credited, at the item's selling price. No customer is named. No invoice exists. No tax is computed. The money is assumed to have arrived in cash.
Why this exists, because it is not an accident
There are real cases where a stock issue is a sale: an over-the-counter cash sale from a hardware store's back room, a staff purchase, a bar issuing stock against till takings. The flag lets those be recorded in one action instead of an issue plus a separate manual sales entry. For a small trader that is a genuine convenience and the reason the feature is worth having at all.
The flag is not the problem. The problem is that the person who sets it and the person who chooses it are almost never the same person, and only one of them knows what it does.
Three ways this goes wrong
-
The helpful reason nobody audited
Somebody creates "Sample to customer" and ticks the revenue flag, reasoning that a sample is stock going to a customer. Every marketing sample from then on posts revenue at full selling price and cash that never arrived. Revenue is overstated, cash is overstated, and the difference sits in the accounts until a bank reconciliation cannot be made to work.
-
The right reason with the wrong price
A staff sale at a 40% discount posts revenue at the item's full selling price, because the selling price on the item master is what the entry uses. There is no discount, no override and no price field on the issue. Revenue is overstated by the discount on every staff sale, forever, and nothing on the record hints at it.
-
The reason that got renamed
This one is a mechanical trap rather than a judgement error, and it is worth knowing about specifically. The reason is stored on the issue as its name, not as a reference to the reason record. At approval the system looks the reason up by that name and fails outright if it cannot find it. So an issue raised on Monday under "Damaged", with the reason renamed to "Damaged goods" on Tuesday, cannot be approved on Wednesday. Not degraded — refused.
One mis-flagged reason, one quarter
The insidious part is that the quarter looks good. Revenue is up, gross margin is 36%, and the only symptom is a cash account that will not reconcile — which the person doing the bank reconciliation will assume is their own error for at least a month. A mis-flagged reason does not announce itself as a problem. It announces itself as a strong quarter.
The controls that do exist around the same issue
It would be unbalanced to describe the reason flag without the genuinely strong controls sitting alongside it on exactly the same transaction.
- Nothing moves until approval. An issue is raised as pending. The stock decrement and every journal entry happen when it is approved, not when it is requested — so a mistake caught at the review stage costs nothing.
- High-value issues need an elevated permission. Above a value threshold you set, an issue cannot be approved without a specific grant. The person who can release ordinary material cannot release a large amount of it.
- Held stock is respected. An issue can be drawn from a specific reserved allocation rather than from general stock, and it will not silently consume material that was set aside.
- Quality holds are enforced at the allocation itself, so quarantined, expired or damaged stock cannot be issued regardless of the reason chosen.
- The job coding is on the same form. Material can be charged to a job at the item's cost, which is what makes production costing possible without a recipe.
- Custom fields on adjustments, so a run number, a grade or a machine can be captured and made mandatory.
- Full audit logging, so who raised it, who approved it and what changed is recoverable.
Read together, the picture is a well-controlled transaction with one unguarded parameter. The approval gate, the threshold and the holds are all real. The reason flag sits inside all of them and is checked by none of them, because from the system's point of view a revenue-generating reason is a legitimate configuration and not an exception.
What to actually do
A twenty-minute review, worth doing once
- List every reason and check the revenue flag on each one. This is the whole exercise and most firms find at least one surprise.
- For any reason that is flagged, confirm that cash genuinely arrives every time it is used. If it sometimes does and sometimes does not, the flag is wrong — split it into two reasons.
- For any flagged reason where the price is ever discounted, unflag it. Post the sale properly through an invoice or the point of sale instead, where a price can be set and tax computed.
- Name reasons so the accounting is visible in the label: "Staff sale — posts revenue" reads differently at the store window than "Staff sale".
- Treat the reason list as change-controlled. Renaming a reason with issues pending approval will block those approvals, so add a new reason and retire the old one instead of editing it.
- Keep the list short. Fifteen reasons means nobody reads them; six means the choice is deliberate.
Three questions for any inventory system, not only this one
Can a stock adjustment post revenue?
What you will hear
Usually a confident no, then a check, then sometimes yes.
How to read it
Adjustment-driven revenue exists in a lot of small-business systems because it is convenient for cash traders. It is not wrong to have it — it is wrong not to know you have it, because it is the easiest route to revenue in your accounts with no document behind it.
What price does an adjustment use — cost or selling?
What you will hear
Cost for the stock side. Ask separately about the revenue side.
How to read it
If a revenue entry uses the item master's selling price with no override, every discounted transaction on that path overstates revenue and nothing on the record shows it.
Is the reason stored as a reference or as text?
What you will hear
Almost nobody knows this off the top of their head.
How to read it
Stored as text, renaming a reason detaches history from it — and if anything looks the reason up later, that lookup can fail. Worth a direct test: rename a reason and then try to approve an adjustment raised under the old name.
What AWRA OpsHub does today
- A reason required on every adjustment, from a list you maintain, with a name and a description.
- A revenue flag per reason, which additionally posts cash debited and sales revenue credited at the item's selling price.
- Approval before anything moves — the stock decrement and all journal entries fire on approval, not on request.
- A value threshold requiring an elevated permission to approve a high-value adjustment.
- Issue from held or reserved stock, from a specific warehouse and bin, with quality holds enforced by the allocation itself.
- Charge to a job at the item's cost, so material consumption lands on the work that consumed it.
- Custom fields on adjustments, requirable, so a run or machine reference can be mandatory.
- Full audit logging of who raised, changed and approved.
What it does not do
- No warning that a reason posts revenue. The flag is invisible on the form where the reason is chosen.
- No price override on a revenue-posting issue. It uses the item master's selling price, so any discount overstates revenue.
- No customer on the entry. Revenue is posted with no counterparty, so it appears in no customer's history and on no statement.
- No tax computed. A revenue-posting issue does not raise VAT, which for a genuine sale is a compliance problem rather than a rounding one.
- Cash is assumed. The debit goes to cash rather than receivables, so an unpaid transaction on this path overstates cash from the moment it posts.
- The reason is stored as text, not a reference. Renaming a reason blocks approval of any adjustment already raised under the old name, and the failure is a hard one.
- No approval requirement specific to revenue-posting reasons. The ordinary threshold applies; nothing treats a revenue entry as needing more scrutiny than a write-off.
- No report of revenue posted by adjustment, so separating it from invoiced revenue is a query you write.
The honest position: we would not build the revenue flag this way today, and it is genuinely useful to the cash traders it was built for, so the answer is guard rails rather than removal — a visible marker on the form, a price override, a customer, and a distinct approval. Until those exist, the twenty-minute review above is the whole defence, and it is a good deal more effective than it sounds because the failure mode is a single wrong tick that then repeats silently.
Our take
Go and look at your reason list this week. Not because something is broken, but because a handful of booleans set once during setup are quietly deciding whether stock movements become revenue in your accounts — and that is too consequential a decision to leave to whoever configured the system in week one and has since moved on.
Audit your reason list
Six reasons, each with a name that says what it does to the ledger, and none of them flagged for revenue unless cash genuinely arrives every single time.
See stock adjustments