Eight Fields That Freeze a Moment
Every quotation, invoice and till sale carries eight fields recording the conditions it was raised under — country, currency, tax type, tax rate, whether tax applied, whether it was inclusive, the exchange rate, and the moment it was captured. Change any of those settings tomorrow and the document does not move.
Most arguments about historical documents come down to one question: was this produced under the rules that applied then, or under the rules that apply now? A system that cannot answer it will eventually show you a document that has quietly changed.
The position, up front
Ours can answer it. Every sales document freezes eight fields at the moment it is raised — country, currency, tax type, tax rate, tax enabled, tax inclusive, exchange rate and a timestamp — and every reader of those values takes them from the snapshot rather than from today's settings. Change your tax configuration and last quarter's invoices are untouched. This is one of the better-designed things in the product.
What is frozen
Eight fields, and each of them is a setting that could otherwise move under a document's feet.
| Field | What it protects against |
|---|---|
| Country | An organisation whose registered country is corrected later |
| Currency code | A document being re-read in whatever currency is current |
| Tax type | A change in which tax regime is applied |
| Tax rate | A rate change silently restating historical tax |
| Tax enabled | A business that registers, or deregisters, mid-year |
| Tax inclusive | A change in whether displayed prices include tax |
| Exchange rate | A rate that moved after the document was raised |
| Captured at | Any argument about which of the above applied when |
The fifth row is the one that catches people out most often, and it is the strongest argument for the whole design. A business that becomes registered for tax part way through a year has two genuinely different sets of documents. Without a snapshot, whichever setting is current wins, and the earlier ones are restated by a switch nobody connected to them.
A setting is a fact about now. A document is a fact about then. Confusing the two is how a historical record quietly becomes a current one.
How it is actually read
This is the part that makes it work rather than merely exist. Every value has a reader that takes the snapshot and a fallback. So a document with a snapshot uses it, and a document from before the snapshot existed falls back to current settings gracefully instead of failing.
That pattern is worth recognising in any product you evaluate. A snapshot that is written and not read is decoration; a snapshot that is read without a fallback breaks on historical data. Getting both right is the whole implementation.
It is applied consistently, too: customer invoices, quotations, point-of-sale sales and supplier-side documents all carry one. It is not a feature of the invoice screen; it is a property of documents.
Why this matters more when you trade across a border
A Hong Kong business is frequently the point at which several jurisdictions meet — a buyer in one, a supplier in another, an invoice in a third currency, and a set of conditions that were true on the day and are not permanent.
In that setting the exchange rate field earns its place on its own. A document raised at one rate, read a year later at another, is a document that has changed value. Recording the rate at capture means the document reads at what it was worth, and the difference between then and now is a question you can ask rather than an error you have to find.
Which leads directly to the boundary.
What the snapshot does not do
It records the rate. Nothing revalues on it. There is no exchange-difference accounting, realised or unrealised, and no revaluation of open items when a rate moves. The books are kept in one base currency per organisation, fixed at setup, and the snapshot does not change that.
So the correct summary is that the snapshot gives you an accurate historical record and does not give you a treasury position. Those are different products, and it would be misleading to let the first imply the second.
Two smaller boundaries worth knowing. The snapshot is per document, not per line — a single invoice mixing two tax treatments carries one snapshot. And recording a tax rate is not filing a return: outside Kenya, nothing is transmitted to any authority.
What would build on this
The snapshot is the hard part and it is done. Everything below is a consumer of data that is already being captured correctly, which makes each of them smaller than it would be from a standing start.
Exchange difference reporting
The rate at capture is recorded and the rate at settlement is knowable. The difference between them is a number nothing currently computes.
A rate-change impact view
Open documents grouped by the rate they were captured at, so exposure to a move is visible before it is realised.
A per-line tax context
For invoices genuinely mixing treatments. Larger than it sounds, because it moves the snapshot down a level.
No dates on a public page. If exchange-difference accounting is a reporting requirement rather than a curiosity, describe it and we will scope it in writing.
Scope currency reportingWhat AWRA OpsHub does today
- Eight fields frozen on every quotation, customer invoice, point-of-sale sale and supplier-side document: country, currency, tax type, tax rate, tax enabled, tax inclusive, exchange rate and capture time.
- Typed readers for every value that prefer the snapshot and fall back to current settings, so historical documents from before the snapshot existed still read correctly.
- A separate country snapshot on customer invoices.
- Tax applied per line on invoices, with the document-level treatment recorded in the snapshot.
- Documents that do not move when your organisation's settings change.
What it does not do
- Any revaluation on the recorded exchange rate. Nothing recomputes when a rate moves.
- Realised or unrealised exchange difference accounting.
- A second base currency — the books are kept in one, fixed per organisation at setup.
- A per-line tax context. The snapshot is per document.
- Any transmission to a tax authority outside Kenya.
Not ours, by choice
- This is a record-keeping feature, not a treasury one. It makes your history correct; it does not tell you your exposure.
- The fallback pattern is what makes it safe on existing data, and it means an old document without a snapshot reads at current settings — which is the best available answer rather than a perfect one.
- Nothing here is specific to Hong Kong. It is what a snapshot is worth; trading across borders is where it is worth the most.
Three questions about historical documents in any system
Change your tax rate setting, then open last quarter's invoice. What does it show?
A good answer sounds like
The old rate.
What it actually means
The whole question, and it takes two minutes to test. A great many systems fail it and nobody finds out until an audit.
What exchange rate is on this document, and where did it come from?
A good answer sounds like
A stored rate with a capture time.
What it actually means
A document that resolves its rate at read time is a document whose value changes daily.
What happens to documents raised before you added snapshots?
A good answer sounds like
A stated fallback.
What it actually means
The honest answer here matters more than the feature. A system that breaks on its own history has not finished the work.
Test the snapshot on your own data
Change a setting in a test organisation and open an old document. Two minutes, and it will tell you more about a system's handling of history than any feature list.
Run the test with usFrequently asked questions
Does the snapshot affect what the ledger records?
The ledger is kept in the organisation's single base currency, and the snapshot records the conditions the document was raised under. So the snapshot governs how the document reads and reports; it does not create a second set of books.
What if the exchange rate on a document is wrong?
It is a stored value on the document, so correcting it is a correction to that record rather than a recalculation of everything. That is the right shape — but note there is no revaluation either way, so a corrected rate changes the document and nothing downstream of it.
Can one invoice carry two tax treatments?
Tax is applied per line, so the amounts can differ line by line. What is captured once, at document level, is the context — the rate, the type and whether tax was enabled and inclusive. For most invoices that is the same thing; for a genuinely mixed invoice it is a simplification worth knowing about.
