Sooner or later somebody asks. An accountant at year end. A franchisor. A bank looking at a loan application. A tax authority opening an enquiry. They want every sale, in order, with nothing missing and nothing quietly edited afterwards — and if the answer is a spreadsheet somebody typed up later, that is a long afternoon.
On Ontabee, every order and every payment is written down as it happens, into an append-only chain of records — one chain per location, where each record is hashed over every field it stores plus the hash of the record before it. Below: exactly what gets recorded, how the records are linked, and the parts we have not built yet.
Card takings reconcile, roughly. Two refunds were handled over the phone. One order was cancelled and re-entered because the kitchen misheard it. Nobody can now say for certain whether the list you are holding is everything that happened — or everything that happened, minus whatever got tidied up along the way.
Almost every operator asked to prove their takings has done nothing wrong. What they are missing is a record that was written at the time, in sequence, by the system that actually took the order — rather than one reconstructed afterwards out of exports and memory.
To be clear about what this is not: Ontabee does not change what you owe or what you have to file, and nothing on this page is tax or legal advice. It changes what you are able to put in front of someone when they ask what came through your ordering channels.
Every one of these is written as it happens, and stays. Nothing is rolled up into a daily total and thrown away.
The order as placed, then each status transition after it — accepted, rejected, cancelled, completed. A cancelled order does not disappear: the cancellation is itself a record, sitting in sequence where it happened.
Payment captures, refund initiations and refund settlements, each as its own record. Amounts are carried at full precision — four decimal places — so nothing is rounded on the way into the record.
A UTC timestamp, plus the business day at that location — a kitchen closing at 1am puts those orders in the previous day’s takings, where your accountant expects to find them. The acting user is recorded, and if a support session was impersonating that user, that is recorded too.
| Event | On the record chain today |
|---|---|
| Order placed | Recorded |
| Order accepted | Recorded |
| Order rejected | Recorded |
| Order cancelled | Recorded |
| Order completed | Recorded |
| Payment captured | Recorded |
| Refund initiated | Recorded |
| Refund settled | Recorded |
| Gift-card purchase | Not yet |
| Independent outside timestamp | Not built |
| Check the chain yourself, unaided | Not built |
The three “not” rows are the honest edge of this feature, and they are explained further down rather than buried.
You do not need to follow the mechanism to benefit from it. But you should be able to check that we can explain it in four steps without hiding behind the word “blockchain”, because we are not one.
Every field recording what happened goes into a SHA-256 hash — not a subset, not just the total. Change any single one of them and the hash changes.
The previous record’s hash is part of what the next record hashes. That turns the records from a pile of rows into a chain with a defined order.
Records are added, never rewritten in place. Each location has its own single linear chain, so one branch’s busy Friday cannot disturb another branch’s sequence.
A checker walks a location’s chain and, where the links stop matching, names the exact record at which it diverges — not a vague failure. The serialization used for hashing is versioned, so improving the format later cannot invalidate records already written under the old one.
What that gets you in practice: quietly editing one field of one old order — or deleting it — does not leave a neat gap. Every record after it stops matching, unless the whole chain from that point is rebuilt as well. Which is exactly why the next section exists, because rebuilding is the case we have not closed off yet.
This site has a standing rule: an unverifiable claim about your records is worse than no claim at all, especially to somebody whose worry is a tax inspector. So here is the unflattering half.
The record chain and the checker that walks it both live inside the platform. There is no dashboard screen, no API route and no downloadable script that lets you, or your accountant, run that check independently today. You can export your full order and payment history whenever you want — that has been true for a while and is described on our Security page — but exporting data is not the same as verifying a chain, and we are not going to let the two blur into each other in your mind. The day self-serve verification ships, it gets described right here.
Nothing about the chain is currently registered, stamped or published anywhere beyond Ontabee. So the protection against a record being removed by somebody with direct database access is operational — access control, audit logging, encrypted backups — rather than mathematical. Until that changes, the honest description is the one used on this page: records that are linked, ordered and checkable. Not records that nobody could rewrite.
Ontabee holds no approval under any country’s fiscal-software or invoicing rules, and no country-specific adapters have been built — not for Spain, France, Portugal, Germany, Italy, Greece, India or the United Kingdom. What exists is one general-purpose record chain, exactly as described above. If your jurisdiction requires approved invoicing software, Ontabee is not that. Ask us before assuming otherwise, and we will tell you straight.
Orders, order status changes, payment captures, refund initiations and refund settlements are. Gift-card purchases are not yet. And there is no customer-facing screen for any of this — a diner sees a normal receipt, not a hash.
We take the same approach to certifications generally: we do not hold SOC 2 or ISO 27001 and say so plainly on the Security page rather than implying a badge we have not earned.
Context about the industry, not a claim about Ontabee. Two things have shifted, and neither of them depends on which ordering platform you use.
In the UK, digital platforms have been required to report seller income to HMRC annually since 1 January 2024. Where rules like that apply, the authority can hold a figure for somebody’s online sales before that person sends it one. Having your own complete, ordered record is what turns a mismatch into a five-minute conversation instead of a months-long enquiry.
Several jurisdictions are moving from regulating the restaurant to regulating the ordering and EPOS software the restaurant runs. Spain’s Veri*factu mandate, phasing in from 2027, is the most concrete example so far. That direction of travel is why we built a record chain now, rather than the week somebody demanded one — while being equally clear, above, that we support no such regime today.
Not yet. The record chain and the checker that walks it both live inside the platform; there is no screen in your dashboard, no API route and no downloadable script that lets you or your accountant run the check independently today. You can export your full order and payment history whenever you like, but exporting data is not the same as verifying a chain and we will not blur the two. When self-serve verification ships, it will be described on this page.
It means an alteration does not stay quiet. Each record’s hash covers every field of that record plus the hash of the record before it, so changing or deleting one record breaks every link after it unless the rest of the chain is rebuilt too. What we do not yet have is an outside witness: nothing about the chain is registered or stamped anywhere beyond Ontabee, so protection against removal by someone with direct database access rests on access control, audit logging and backups rather than on mathematics.
No. Ontabee holds no approval under any national fiscal-software or invoicing regime, and no country-specific adapters have been built — not for Spain, France, Portugal, Germany, Italy, Greece, India or the United Kingdom. What exists is one general-purpose record chain, described on this page. If your jurisdiction requires approved invoicing software, Ontabee is not that, and you should ask us before assuming otherwise.
Yes. Payment captures, refund initiations and refund settlements are each written as their own record, alongside the order records they belong to. Amounts are carried at full precision — four decimal places — so nothing is rounded on the way into the record. Gift-card purchases are not on the record chain yet.
No, and anyone telling you otherwise is selling you a problem. Nothing here changes what you owe, what you must file, or when. It changes what you can put in front of someone who asks what came through your ordering channels. Nothing on this page is tax or legal advice — talk to your accountant about your obligations.
Each location keeps its own separate chain, in its own currency and its own business-day boundary, so a late-closing branch does not disturb another one’s sequence. Every restaurant’s records are isolated from every other restaurant on the platform — tenant isolation is built to deny access rather than risk leaking it.
Payments through your own provider, credentials in a vault, tenant isolation, backups — and what we deliberately don’t claim.
Ordering, dine-in, kitchen display, marketing, reporting. Commission-free at every tier.
Managing several restaurants at once, each with its own isolated records, from one place.
See also our Privacy Policy and DPA, the guide on what “own your data” actually means, and — if you are one of the restaurants that has to move before April 2027 — GloriaFood alternatives compared and how migration works.
Commission-free ordering, every order and payment kept in order and in sequence, and a full export the day you ask for one.
Start free Ask us about records