The Balances That Never Agree
The same event, recorded twice, in two systems, in two currencies, on two dates, under two descriptions. The difference is explained rather than resolved, and it comes back next year.
Every group with operating subsidiaries has an intercompany reconciliation, and in almost every one of them it is the least loved schedule in the pack. It is prepared late, it never fully agrees, the difference is described rather than eliminated, and the same conversation happens again the following year with a different number.
It is tempting to treat that as a discipline problem. It is not. The reason intercompany balances do not agree is structural, and once you see the structure the persistence stops being mysterious.
One event. Two records. Created independently, by different people, in different systems, in different currencies, on different dates, described in different words, and — this is the part that matters — with no single object anywhere that both records are versions of.
Four ways one event becomes two disagreeing records
| The mechanism | What it produces | Why it survives every clean-up |
|---|---|---|
| Two dates | Charged on the 28th, posted on the 3rd. Across a period end, both sets of figures are correct and different | Nobody is wrong, so there is nothing to correct — only to explain, every period, indefinitely |
| Two currencies | Charged in dollars, recorded locally at one rate, translated back at another. Three numbers, all defensible | The residual lands in an exchange line that nobody interrogates because exchange differences are expected to exist |
| Goods as well as money | Inventory leaves one balance sheet in one month and joins another in the next, sometimes at a different value or quantity | Unrealised margin on group stock depends on knowing which units are still on hand, and very few groups genuinely do |
| Charges with no artefact | Shared services, group insurance, a seconded engineer, an allocation of head office cost | There is nothing to point at. The charge is real and the evidence for it was never a document in the first place |
Two records of one event, and no object anywhere that either of them is a version of. That is the whole problem, and it is why tidiness never fixes it.
The one that gets expensive: charges with no artefact
The first three mechanisms produce reconciliation work. The fourth produces exposure, and it is worth separating out.
A management charge, a cost recharge, an allocation of shared services — these are ordinary and legitimate. The difficulty arrives when a tax authority in the operating country asks what the subsidiary actually received for the amount it paid, and the answer has to be reconstructed from memory, email and somebody's recollection of a staffing arrangement three years ago.
-
The arrangement is real and sensibly conceived
Head office genuinely provides something — procurement leverage, technical support, systems, a seconded engineer, group insurance cover. The charge reflects a real benefit and the policy was set with advice.
-
The charge is calculated at a level of abstraction
A percentage of revenue, an allocation by headcount, a fixed monthly amount. Perfectly normal, and it deliberately does not itemise, because itemising every instance of head office value would be absurd.
-
The underlying activity is recorded somewhere else, or nowhere
The engineer's time is in a timesheet in another country, or in nobody's. The procurement benefit is in a set of purchase orders in a different system. The support is in a ticket queue, or in a WhatsApp group.
-
Years pass and people leave
The person who designed the arrangement moves on. The person who could describe what was actually delivered in a given year is no longer with the group.
-
Then somebody asks
A tax authority, a minority shareholder, an acquirer in diligence. The policy documentation exists and is fine. The evidence of delivery is an archaeology project, and its absence reads worse than it deserves to.
A boundary worth stating clearly
Nothing here is transfer-pricing advice and no software substitutes for it. Setting the policy, benchmarking the charge and producing the documentation is your advisers' work, and it should stay there. The argument is narrower and entirely practical: where the operational substance behind a charge — the hours, the purchase, the asset, the project it was consumed by — happens to sit in the same system as the entity records, then evidence is retrieved rather than reconstructed. That is not a compliance capability. It is a filing cabinet in the right place.
What actually reduces the difference
Four things, and only the last of them is about software.
In order of how much they help
- Agree a cut-off convention and hold both sides to it. Most of the timing difference is one party posting on receipt and the other on issue. This is a policy decision, it costs nothing, and it removes the largest single component.
- Fix the rate convention. Decide whether intercompany transactions are recorded at the transaction rate, a monthly rate or a group rate, write it down, and make sure both sides use the same one. Currency differences that remain after that are real rather than procedural.
- Reconcile monthly rather than annually. A monthly difference is a specific transaction somebody remembers. A twelve-month difference is an archaeology project with a deadline attached and a partner waiting.
- Make the transaction exist once, with both parties looking at the same record, rather than twice with a hope that they match. This is the only one that requires a system, and it is the only one that stops the difference arising rather than making it easier to explain.
The first three will get most groups most of the way, and they can be done this quarter with no purchase. It is worth doing them before concluding that the problem needs a system, because the residual after those three is a much better description of what a system would actually be solving.
Four questions for your next reconciliation
What is the largest intercompany difference?
The answer you often get
We reconcile these annually.
What to press for instead
Ask both entities for the balance independently, before anybody explains anything, and look at the gap cold. The explanation is usually available and usually correct; what is informative is how long it took to produce and how much of it is timing.
What rate is used for intercompany charges?
The answer you often get
The month-end rate.
What to press for instead
Ask the other entity the same question separately. A surprising proportion of groups discover that the two sides have been using different conventions for years, each perfectly consistently.
What evidence supports the management charge?
The answer you often get
There is an agreement in place.
What to press for instead
An agreement establishes that a charge is payable. Ask what evidences what was delivered in a specific year — hours, tickets, purchases, projects. If the answer is a person's recollection, note that the person is a single point of failure with a multi-year lookback attached.
How much unrealised margin is in group stock?
The answer you often get
It is calculated at year end.
What to press for instead
Ask what it is calculated from. It depends on knowing which specific units transferred between entities are still on hand, and if nobody tracks that at item level, the figure is an estimate presented as a computation.
What AWRA OpsHub does today
- Multiple entities on one operational basis, each a distinct position
- Transfers between entities that stay open until the receiving end confirms quantity
- Original currency and the rate actually applied retained on the transaction
- Project, cost centre and asset attribution consistent across entities
- Hours, purchases and asset usage recorded where the work happened
- A full audit trail of who changed what and when
What it does not do
- Statutory consolidation, eliminations or unrealised margin computation
- Group financial statements or a translation reserve
- Transfer-pricing benchmarking, policy setting or local file production
- Automatic intercompany matching or a settlement mechanism
- Any Singapore statutory payroll or GST capability
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 tax authority pipeline, a local-language interface, a bank or mobile money feed, a statutory return format 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.
Tax authority pipelines and reporting
Electronic invoicing against your authority's published interface or its accredited network, with retries, a failure queue and a daily report of sales that never reached it. The regimes here range from a live clearance model to a purely voluntary scheme, so this is one build per country and we will say which country rather than sell an ASEAN integration that does not exist.
Local-language interface, banks and wallets
Interface text and document templates in the language your finance floor and your statutory documents actually require, plus real-time payment collection, e-wallet settlement and bank statement feeds wired into the Payments Register.
Payroll and statutory returns
Social security, provident fund and withholding computed on live records, with the contribution files produced in the layout each agency expects and any statutory bonus accrued through the year rather than found at the end of it.
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 take
Do the three free things first — a cut-off convention, a rate convention, and monthly rather than annual reconciliation. In most groups that removes the majority of the difference and it can be agreed in a single call. What remains is the part worth thinking about systemically: transactions that exist twice rather than once, and charges whose supporting substance lives in a different place from the charge itself. Neither of those is fixed by tidiness or by a better spreadsheet, and both get quietly more expensive the longer a group operates.
One transaction, not two
Transfers with confirmation at both ends, the original currency and rate retained, and the operational substance behind a charge sitting in the same place as the entity records.
Talk to us about SingaporeFrequently asked questions
Why do intercompany balances never agree?
Because one event produces two independently created records, and there is usually no single object that both are versions of. The four mechanisms are timing — one side posts on issue, the other on receipt; currency — the same amount recorded at different rates and translated back at another; goods, which leave one balance sheet in one period and join another in the next; and charges with no underlying artefact at all. None of those is carelessness, which is why they survive every clean-up and reappear the following year.
What is the cheapest thing that helps?
Agreeing a cut-off convention and holding both sides to it. In most groups the largest single component of the difference is timing, and timing is a policy question rather than a systems one. Second is a shared rate convention, written down, with both entities confirming they use it. Those two conversations can happen this week, cost nothing, and will tell you how much of the residual is genuinely structural.
Do you handle unrealised margin on group stock?
No — we do not compute it, and eliminations of any kind are outside what we do. That is a consolidation function belonging to your accounting system and your auditor. What we can hold is the input the computation depends on: which specific units transferred between entities, at what value, and whether they are still on hand at the receiving location. Where that is tracked at item level, the elimination becomes a calculation. Where it is not, it becomes an estimate presented as one.
Is this a transfer-pricing article?
Deliberately not, and we would rather over-state that boundary than blur it. Setting a policy, benchmarking a charge and producing documentation is advisory work and no software substitutes for it. The narrow practical point here is about evidence rather than policy: when a tax authority in an operating country asks what a subsidiary actually received for a charge, the answer is easier when the hours, purchases, assets and projects behind it live in the same system as the entity records. That is filing, not compliance.
Can software make the transaction exist only once?
For transactions between entities that are both on the same operational system, largely yes — a transfer becomes one movement with two confirmations rather than two independent entries hoping to match, and the currency and rate travel with it. For everything else it cannot, and it would be dishonest to imply otherwise: a group with four accounting systems will still have four sets of records. This is a reason to be realistic about sequencing rather than a reason not to start.
How often should we reconcile?
Monthly, and the argument is practical rather than technical. A monthly difference is a specific transaction that somebody still remembers and can resolve in minutes. A twelve-month difference is an investigation, conducted under time pressure, by people who were not involved, with an auditor waiting. The first reconciliation is much more work than every subsequent one, which is the usual reason a group never starts and the reason it is worth pushing through once.
