Every order and payment is written down as it happens, into an append-only chain of records. Each trading day is sealed and timestamped by an authority outside Ontabee, so a rewritten history is detectable by somebody who is not us — and your accountant can check the whole thing on their own laptop, offline, without an account.
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 |
| Refund failed | Recorded |
| Order items or prices edited | Recorded |
| Gift-card purchase | Recorded |
| Receipt & credit note issued | Recorded |
| Check the chain yourself, unaided | Yes — in the export |
| Independent outside timestamp | Yes — on every plan |
The rows that still say no 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.
At the end of each business day every location’s records are reduced to one value, those values are combined into a single value for the whole business, and that is sent to an independent timestamping authority — which returns a signed token saying it saw that exact value at that moment. One stamp a day covers every branch, and each branch keeps a short mathematical proof that its own day is inside it.
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 — and a rebuilt chain cannot reproduce a timestamp an outside authority issued yesterday over the old value. The honest edge of that is in the next section: it makes a rewrite detectable, which is not the same as impossible.
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.
You can now run the check yourself, and that is worth something — but be precise about what it shows. It confirms the records are internally consistent and that none has been altered since it was written. It does not show that alteration was impossible. The hashes use no private key, so somebody with direct access to the database, working before anyone had a copy of the day’s totals, could in principle produce a different but equally consistent history. What narrows that gap is the outside witness described in the next item — a rebuilt chain cannot reproduce a timestamp someone else issued yesterday. It narrows it rather than closing it: records written and altered within the same day, before that day was sealed, are still beyond what any of this can detect. Anyone selling you cryptography as a guarantee of honesty is overselling it.
Since 14 August 2026 each day’s records are sealed into a single value and timestamped by an authority outside Ontabee, which is what makes a wholesale rebuild of the chain detectable. Three honest limits. The timestamp runs forward from that date — a timestamp attests that records existed no later than when it was issued, so it cannot reach back and vouch for a day that closed before it. The authority we currently use is a genuine independent third party but is not an eIDAS-qualified trust service provider; moving to one is a contract, not a rebuild, and every day’s record already stores which authority stamped it. And a day is sealed once, at the end of the day: records written and altered within that same window, before it closed, are beyond what this detects.
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. So are gift-card purchases and voids, which sit on a chain kept for the business as a whole rather than for one branch, because a gift card belongs to the company and not to the till it was sold at. What is not there is a customer-facing screen — 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.
Yes. There is a screen in your dashboard that lists your trading days and checks any of them on demand, and you can download an export for whatever period you choose. The export is the part that matters: alongside your records it contains a small checker program that recomputes every hash from the record contents. It depends on nothing of ours — your accountant can run it on their own machine, offline, without an account and without taking our word for anything. What it proves is that the records are internally consistent and unchanged; see the next answer for what it does not prove.
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. And rebuilding the chain no longer helps, because at the end of each business day your records are sealed into a single value that is timestamped by an authority outside Ontabee. A chain rebuilt afterwards cannot reproduce a timestamp somebody else issued yesterday. What that gives you is detection, not prevention: it does not make alteration impossible, and anyone selling you cryptography as a guarantee of honesty is overselling it.
No. Several countries require invoicing software to be formally approved — Spain, France, Portugal, Germany, Italy, Greece and India each run their own scheme, and the UK is consulting on one now. Ontabee holds none of those approvals and has built no country-specific adapters. What exists is one general-purpose record chain that works identically everywhere, described on this page. If your country requires approved invoicing software, you will need that as well as this. Ask us and we will tell you exactly where we stand: we follow these schemes closely enough to have responded to the UK consultation and to have read Spain’s technical specification line by line.
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 recorded too: they belong to no single branch, so they sit on a record chain kept for the business as a whole rather than a branch one.
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