Stock Value With Nowhere to Put a Branch
Ask our stock reports what the Christchurch warehouse is holding and you get an answer. Ask the ledger the same question and there is nowhere for it to look, because a journal entry has no branch on it. Two views of the same goods, one dimensioned and one not.
A New Zealand business with a North Island and a South Island operation is one company that behaves like two, and every reporting question it asks eventually runs into the same wall: can this number be split?
For stock, yes. For the ledger, no. And the reason is a single absence that is easy to state and expensive to discover late.
The two views
Physical stock is held per warehouse and per bin location. Every movement records where it happened. Valuation, counting, transfers and reporting all work at that granularity, and a per-site stock report is an ordinary thing to ask for.
The ledger underneath is a different shape. A journal entry carries an account, an amount, a reference, a description, and a link to the adjustment or item that produced it. It does not carry a branch, a department or a project. There is no dimension on it at all.
So the inventory asset account has one balance for the organisation. The trial balance cannot be sliced. The two views are consistent with each other and only one of them can be cut by site.
The stock knows where it is. The money does not.
Where the wall is actually hit
| The question | Where the answer comes from | Available? |
|---|---|---|
| What is on hand in Christchurch? | Stock reports, per warehouse | Yes |
| What is Christchurch stock worth? | Stock valuation, per warehouse | Yes |
| What did Christchurch consume this month? | Movement history, per warehouse | Yes |
| What is the inventory asset balance for Christchurch? | The ledger | No — there is no branch on a journal entry |
| What is the trial balance for the South Island? | The ledger | No |
| Do stock and ledger agree overall? | The internal integrity check | Yes, and this is genuinely built |
The last row deserves its place. There is an integrity check that compares the ledger against stock, against open purchase orders, and debits against credits, and it works. What it cannot do is tell you which site a discrepancy came from.
The distinction that gets blurred in demonstrations
A vendor showing you per-warehouse stock reports is showing you something real. It is easy — for everybody in the room, including the vendor — to take that as evidence that the financial side is dimensioned too. It is a reasonable inference and it is wrong here.
The test is not whether stock can be filtered by site. It is whether an account balance can. Ask for the inventory asset account for one branch, not for the stock on hand at one branch. Those sound like the same question and they come from different halves of the system.
What to do about it
-
Decide early whether you need a branch profit-and-loss
If the answer is yes and it is a real business requirement rather than a preference, the shape that works is one organisation per branch, with consolidation outside. That is a significant decision with real costs — separate logins, separate masters — and it is far cheaper before go-live than after.
-
If you do not, use the stock side and stop asking the ledger
Most operational management is answerable from the physical view: what is where, what moved, what it is worth. The ledger question is usually a reporting habit rather than a requirement, and it is worth checking which one it is.
-
Use departments where they do reach
A purchase order carries a department and budgets are held per department, so spending is dimensioned even though the resulting journal entry is not. That covers more management questions than people expect.
-
Do the branch split in your reporting layer
Export by warehouse, tag it yourself, and consolidate. Unromantic, and the standard answer everywhere until a system has real dimensions.
What AWRA OpsHub does today
- Stock held, valued, counted, moved and reported per warehouse and per bin location.
- Departments on purchase orders, and budgets held per department and category.
- Projects on stock issues and on purchase orders, with issued material costing into a job.
- One cost basis shared by the till, the journal, margin analytics and the stock-integrity check, so those four cannot disagree with each other.
- An internal integrity check reconciling the ledger against stock, against open orders, and debits against credits.
What it does not do
- Any dimension on a journal entry. No branch, no department, no project — so the trial balance cannot be sliced.
- A per-branch profit and loss, or a per-branch balance sheet.
- Manual journal entries, so a dimension cannot be introduced by an adjusting entry either.
- Consolidation across organisations, which is the shape you would use to get branch accounts.
- A period posting lock — a closed month is recorded as closed and does not bar movement.
Not ours, by choice
- The physical view genuinely is dimensioned, and it answers most operational questions. This page is about the financial view only, and the difference between them is easy to miss.
- One organisation per branch is a real option with real costs. It is the right answer when branch accounts are a requirement and the wrong one when they are a preference.
- Nothing here is specific to New Zealand. It is what happens to any two-site business; New Zealand is where the two sites are most likely to be run as two operations.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a local payroll engine, a rate with a date on it, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Dated rates and the periods your obligations actually use
Effective-dated tax rates, so a document raised about a past period is computed against the rate that applied then rather than the rate that applies now, and a credit note that carries the tax split of the supply it reverses. Where a jurisdiction operates a sales-monitoring or fiscalisation scheme, data produced in the published format alongside the approved equipment rather than in place of it.
Banks, payments and pay periods that are not months
Bank statement feeds and local payment rails wired into the Payments Register, and a payroll period that matches your statutory pay cycle rather than the calendar month our schema assumes today. The second is a data-model change and we would quote it as one.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Income tax, superannuation or provident fund contributions computed on live employee records against your own pay cycle, with the returns produced in the layout your authority expects.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur position
Decide the branch-accounts question before you configure anything, because it decides how many organisations you set up and that is not a decision you revisit. If you need branch accounts, run one organisation per branch and consolidate outside. If you need branch operations, the stock side already gives you everything and the ledger question was never the one you meant.
Three questions that separate a stock filter from a real dimension
Show me the inventory asset account balance for one branch.
A good answer sounds like
A filtered account balance, not a stock report.
What it actually means
This is the question. Per-warehouse stock reporting is not evidence that the ledger is dimensioned, and the two are easy to conflate in a demonstration.
What dimensions does a journal entry carry?
A good answer sounds like
A named list.
What it actually means
Ours carries none. Every claim about sliceable financial reporting reduces to this one answer.
Can I post a manual journal to correct a dimension?
A good answer sounds like
Yes, with dimensions on it.
What it actually means
Ours has no manual journal at all, so there is no escape hatch. Worth knowing before an accountant assumes there is one.
How would you give me branch accounts?
A good answer sounds like
An honest architecture answer.
What it actually means
If the answer is "a filter", ask them to show it. If it is "separate entities", that is the same answer we give, and it is the honest one.
Answer the branch question once
One organisation or several is the decision everything else follows from, and it is nearly free before go-live. Tell us how your sites report and we will tell you which shape fits.
Decide the shapeFrequently asked questions
Could a custom field on the journal give me a branch?
No. Journal entries are produced by system flows rather than entered, and the reporting that reads them does not know about custom fields. A dimension has to be understood by the reporting engine to be worth anything, not merely stored.
Does the stock-versus-ledger integrity check still work with multiple warehouses?
Yes — it reconciles the organisation as a whole, which is the level the ledger operates at. What it cannot do is attribute a discrepancy to a site, so investigating one is a manual comparison against per-warehouse stock reports.
Is one organisation per branch really the recommendation?
Only where branch accounts are a genuine requirement — a separate legal entity, a local filing, or a partner who owns part of one site. For internal management reporting the stock and department views usually carry it, and splitting into several organisations costs you cross-site visibility you will miss immediately.
