A blank cell gets investigated. A total that is neatly formatted, carries no warning and happens to be nonsense gets pasted into a board pack. Two of the three controls on this page were written because we shipped exactly that, found it, and fixed the class rather than the instance — which is the part worth telling you about.
It had been doing it for a while, and nothing looked wrong. The report ran, the columns lined up, the total was formatted to two decimal places like every other total in the product. It was only found when a workspace that trades in more than one currency looked closely at a figure that felt slightly high. The sweep that followed found the same shape on the dashboard, in the top-customers report and in credit-hold exposure — all of them sitting on one shared helper that assumed every amount was in the same currency and had two decimal places.
Every workspace we had looked at closely traded in one currency, and in one currency the broken code and the correct code produce identical output. The bug was invisible from the inside and obvious from a market we had not sat in. That is the usual shape of this class of defect, and it is why the fix was a rule rather than a patch.
The tempting repair is to convert everything to one currency and add it up. But a converted display total needs a decision about which rate and as at when; it moves between two viewings of the same closed period; and a total struck at today's rate reconciles to nothing. The ledger converts once, at the rate recorded on each document, and a figure at any other rate matches none of its entries. You would have replaced a wrong number with an unstable one.
One rule, applied everywhere a single money figure is shown: display the largest single-currency total, label it with its code, and disclose how many other currencies sit behind it. No rate is required, the figure is true at every viewing, and the reader knows there is more — which the old single number never told them.
The rule has two halves and the second is the one people argue with, so it is worth being explicit about what it costs and what it buys. It costs you a single all-in number. It buys you a number that can be reconciled, that does not move, and that nobody has to caveat in a meeting.
A dashboard tile, a summary line, a card at the top of a report — anywhere the layout has room for one number. The largest single-currency slice leads, labelled, with a disclosure of the remainder alongside it.
Any surface that knows the workspace's base currency passes it through, and that currency then leads whenever it is present. This matters more than it sounds. Without a rate the only available ordering is by nominal amount, and nominal amounts are not comparable: 215,000 shillings sorts above 38,400 dollars while being worth a fraction of it. Leading with the currency the reader thinks in is both more meaningful and more stable, because it does not reshuffle as balances move.
A report is scoped to one currency rather than summarised across several. You choose the currency, the rows are the rows in that currency, and the totals at the bottom are real totals of real rows. Running it three times for three currencies gives you three reports you can each hand to somebody, which is more useful than one you have to explain.
The nominal ordering described opposite is only ever used to sequence the disclosed remainder. It is never used to claim one exposure is larger than another, because without a rate that claim cannot be made honestly.
If you want a consolidated figure across currencies at a rate you control, that is a legitimate thing to want and it is in the ledger below as work we would do — with the rate and its as-at date stored on the record, so the number can be reproduced later. What we will not do is produce it silently.
The ledger is the one place a conversion happens, and it happens once. A foreign-currency invoice, credit note, customer payment, supplier bill, supplier payment, withholding entry, online collection or till sale posts in your base currency at the exchange rate recorded on that document. When a payment settles at a different rate, the realised difference is booked to an exchange gains and losses account. A document with no rate recorded posts nothing: it shows that it is waiting for a rate, and the refusal is in the audit trail.
Money was stored at two decimal places in 104 columns and formatted with two decimal places everywhere, on an assumption nobody had ever written down: that every currency has two. Of the 137 currencies the product ships tax profiles for, 105 do. 32 do not, and they miss in both directions.
26
currencies at zero places
The larger half, and the one nobody had noticed. It covers 38 of the 188 country rows we ship. XOF alone is the eight UEMOA states and XAF the six CEMAC states — so this is most of francophone West and Central Africa, plus Japan, Korea, Vietnam, Indonesia, Iceland and Hungary.
ALL BIF CLP COP DJF GNF HUF IDR IQD ISK JPY KMF KRW LAK LBP MGA MMK PKR PYG RWF SOS UGX VND VUV XAF XOF
6
currencies at three places
The half that had been noticed, because it is the one that visibly loses money. A Tunisian tax total of 201.900 was being stored and displayed as 201.90 — a real difference, silently discarded on every line.
BHD JOD KWD LYD OMR TND
105
currencies at two places
The assumption, which was right three-quarters of the time. Being right three-quarters of the time is what let it live for as long as it did: any single-market workspace could run for years without meeting the other quarter.
The place count comes from the internationalisation data already bundled with the framework rather than a table we keep by hand, because a hand-kept list is a second copy of a fact somebody else maintains. One consequence worth knowing before you check our figures against a standards document: that data answers “how many digits is this currency written with in practice”, which for a few currencies with an inflated-away subunit is fewer than the formal standard still assigns. The sharpest case is the Iraqi dinar, formally three places and written with none.
This is the control that finance teams ask for and that is most often built wrongly: refuse to release payment when the goods received do not agree with the order. The wrong way to build it is a check in the screen where you noticed the problem. The other four routes stay open, and whoever needs to get paid finds one.
one gate, one definition of “may this be paid”
Those five paths write into two different ledgers, which is the other half of why a per-screen check could never work. Every one of them now calls the same gate before releasing anything, so the answer to “can this be paid” is defined in one place and cannot differ by route.
A control that is right in principle and wrong on the first day gets switched off on the second. These defaults are chosen so that a working business can install the product on a Monday without anything legitimate being refused.
This is the control being asked for. What arrived does not match what was ordered, so the invoice sitting behind it is not yet trustworthy and the payment does not go. It blocks by default, on every one of the five routes.
Deposits, prepayments and proforma terms are legitimate and common, and a product that refused them outright would break working businesses on the day it shipped. So this warns rather than blocks — and an organisation whose policy is that nothing is paid before receipt turns the setting on and it blocks.
Possible, and it should be. It requires a permission that is deliberately not the same one as approving a purchase order — approving an order is routine work, paying past a failed match is not, and collapsing the two would hand the second to everyone who legitimately has the first. It also requires a written reason, and it is stamped with who did it and when.
There is a period close in the product, and it is a lock. It holds the month, the status, who closed it and when, any notes they left, and — if the month was reopened — who reopened it and when. Every journal entry is checked against it as it is written, edited or deleted, whichever part of the product is writing it.
A manual journal dated into a closed month is refused, with the month named, and the person dates it in an open month or reopens the closed one in front of colleagues. An entry already sitting in a closed month cannot be edited, and an edit cannot move an entry into one either. A posted entry is never deleted in any month, open or closed: it is reversed, and the original stays on the ledger beside the entries that undo it.
The lock is enforced on the ledger entry itself rather than on each screen, because there are a dozen things that post — sales, invoices, payments, payroll, expenses, supplier payments, depreciation, manual journals — and a lock any one of them forgot would be a lock that did not exist.
A posting the product makes for you — a till sale, a payment received — is dated today rather than chosen by a person. If an accountant has closed the current month early, that posting lands on the first day of the next open month rather than failing a sale halfway through. Nothing lands in the closed month; the posting moves forward, and its date says so.
What closing a month does not do is post year-end closing entries. Retained earnings on the statements is the profit to date, computed rather than closed into equity by entry, and that is in the ledger below.
This is the sort of thing that normally reaches a customer as “period close” on a feature list and is understood as a lock. If you are comparing products on this row, ask each of them the same question: does closing a period refuse a posting into it, or record that it was closed?
The period lock is the control most people ask about. These three sit beside it, and each one turns a number that would otherwise be typed into a number the system works out and holds you to.
Reconciling a bank account to a statement date works out the ledger balance, the receipts and payments still outstanding, and the difference to the statement. It will not complete while any statement line on or before that date is still unmatched, or while the difference is anything but zero, and it will not complete a date earlier than the last one already reconciled.
Completing it locks every line it cleared, so a matched receipt cannot quietly be unmatched next month to make a different statement agree. A line entered into the books from the statement is refused if its month is closed.
A month’s depreciation is charged once per asset however many times the run is pressed. No charge takes book value below salvage and the last one is whatever is left, so an asset ends on its salvage value exactly. A run into a closed month, or a month that has not started, is refused.
Withholding tax deducted from supplier bills sits in a liability until it is paid over. A remittance larger than what is outstanding for its month is refused, so the liability can reach zero and never go past it.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
Everything in the middle column sits on top of controls that already exist — the period lock, the payment gate, the currency layer. If one of those rows is the one your controller keeps asking about, tell us and we will scope it.
Chart of accounts, journal entries, invoices and the reports that come off them.
Budgets, spend context and the alerts that fire while there is still time to act.
Overdue balances by age, supplier exposure, and who owns the next step on each.
Readiness, mapping, retries and exception ownership before a record leaves for QBO.
Filing at issue rather than at creation, and how a reversal is handled.
The sealed record underneath every figure on this page, and how to verify it.
What posts to the ledger, manual journals tagged by department, branch and project, and the period lock in use.
Statement import, matching against the ledger, and the lock a completed statement leaves behind.
Floats as ledger accounts and imprest retired against receipts, inside the same period lock.
Help Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
