Three Shapes a Receipt Rule Can Take
A rule about receipts can be built three different ways, and only one of them is a feature you can buy. The other two are an architecture and an accreditation. Which one you are under decides whether shortlisting software is a comparison exercise or a much shorter conversation — and the shape that surprises people is the one no feature list will ever show you.
Somewhere in a procurement process, a requirement is written down as a single line: the system must comply with local receipt and invoicing rules. It looks like one requirement. It is three, they are satisfied in completely different ways, and a vendor can honestly answer yes to the line while meaning any one of them.
The variable is not how much the software does. It is where the tax authority sits relative to the transaction — behind it, inside it, or upstream of the software itself. Those three positions produce three kinds of obligation, three kinds of engineering, and three completely different shortlists.
The axis
How far into your business the authority reaches
Records kept, produced on request
The oldest arrangement and still the most common one worldwide. You keep the books; somebody may one day ask to see them. Software has to be good, not approved.
Periodic transmission
Billing records or a ledger file go to the authority on a cycle rather than per document. The obligation is a file in a prescribed schema and a deadline, and it is met by an export rather than by a connection.
Per-document filing, after issue
Each document is sent as it is raised, and a reference comes back. The transaction is complete before the authority hears about it, which means an outage is a queue problem. This is what we built for Kenya.
Authorisation before issue
The authority or an approved device must respond before a valid document exists. The fiscal step is inside the transaction, not after it, and a system built for the position to the left cannot be configured into this one.
The program itself is certified
The authority accredits the software against published requirements and lists it on a register. Nothing you can add to a product satisfies this, because the thing being assessed is the product.
Europe contains all five of those positions, sometimes within a few hundred kilometres of each other. That is why "does it work in Europe" is not a question with an answer, and why a vendor who treats the continent as one market has told you something about themselves.
Three shapes, and what each one actually asks of a vendor
The same requirement, three ways
What the rule says What it is really asking for
File the document An integration
Ordinary engineering against a published interface. Structure the document, send it, store what comes back, retry what fails, and report on what never got a reference. Scopeable, quotable, and finishable. If your regime is this shape, you are running a normal software evaluation.
Authorise before issue An architecture
Not a bigger version of the first one. The fiscal step becomes a precondition of the sale, which means the till stops when the authority does. Everything a vendor built to make the counter resilient to outages exists precisely because their fiscal step is not a precondition. Ask when the product was built, and for which regime.
Certify the program An accreditation
The authority assesses the software and publishes a register of what passed. A vendor either holds it or does not, and no roadmap converts one into the other on a schedule anybody controls. This is the shape that a feature comparison cannot see, because there is no feature.
Transmit periodically A schema and a deadline
Frequently the cheapest obligation in the list and the one most often failed, because it needs the detail behind the documents rather than the documents themselves. A vendor whose export is a header summary cannot produce it, however good the rest of the product is.
Number the documents properly A property, not a field
Every one of the shapes above assumes an orderly, unbroken sequence that belongs to your business. Almost nobody checks this and almost every system claims it. It is the single most testable thing on this page.
Why the third shape is the dangerous one
The first two shapes are visible. They generate integrations, screens, error states and support tickets, so they show up in demonstrations and in reference calls. A buyer running a careful evaluation will find them.
The third shape generates nothing to look at. In Portugal, invoicing software is certified by the tax authority against published requirements and certified programs appear on a public register with a number that goes onto the documents they produce. There is no screen to demonstrate. There is a register to check, and the check takes about two minutes, and a buyer evaluating from outside the country almost never knows to run it.
What a feature evaluation sees
- A product that raises invoices and receipts correctly.
- A QR code rendered on the document, from stored data, in vector.
- A receipt number and a signature printed alongside it.
- Sequential numbering from a locked counter.
- Deletion refused on posted documents.
- A confident answer to "do you handle compliance".
What the register sees
- Whether the program is on it. Ours is not.
- Whether the QR payload is the authority's specification — ours is Kenya's. The renderer is generic; the payload is not.
- Whether the number is an authority-supplied document code. Ours is our own.
- Whether a series was registered in advance. Ours cannot be.
- Whether the records meet the integrity requirements as assessed. We have never been assessed, and refusing deletion is a weaker property than the one being tested.
- A yes or a no, published, with nothing in between.
That second column is not a hypothetical. It is our own audit of our own product against one European regime, and the uncomfortable part is how much of the first column is genuinely true. The QR renderer is in production. The library is there, the vector output is there, the place on the page is there, and a signature and a receipt number sit beside it. What is missing is the specification behind them — which is a smaller engineering problem than it looks and a completely disqualifying one until it is done.
The numbering test, which anyone can run
Every shape on this page rests on the same quiet assumption: that the sequence on your documents is orderly, unbroken and yours. It is the most testable property in the whole subject and almost nobody tests it, so here is ours, including the part we would rather not print.
Document numbers come from a locked counter, held per organization and per year. That is structurally the right shape — it is what a series is, and it is why our numbering is orderly rather than a timestamp with a prefix. But until 6 August 2026, five document types — sales invoices, credit notes, purchase orders, and both point-of-sale sales and returns — were reconciled against a number unique across the whole installation. An organization's sequence could therefore skip, from 41 to 58, for reasons belonging entirely to a different business, with nothing in the interface explaining why.
The counter has been scoped to the organization since that date. The last of those four numbers is the more interesting one, and it is why it is on the page: closing a defect in code is not the end of the job. The blog post that made the finding was corrected the same day. The market page and the block that renders at the foot of tagged posts were not, and for six days this site asserted in one place something it had retracted in another. We found that while writing this post, fixed it, and are telling you rather than quietly moving on.
Where a till stands today, layer by layer
An orderly number from a locked counter, private to your organization
Per organization and per year, taken under a database lock so two simultaneous sales cannot collide. Scoped to the organization since 6 August 2026.
A QR code rendered on the receipt from a stored payload
In vector, at print time, beside a receipt number and a signature. All of it production code — and all of it built to one authority's specification, which is unlikely to be yours.
A fiscal reference on the customer's copy at the counter
The block is conditional on the sale having been filed, and at the instant of printing it has not been. The reference reaches the record, the reprint and every report. It does not reach the paper the customer carries out. Argued in full in the companion post on the EAC.
Both tax identification numbers and the customer's address on the document
All three are stored today and none of them prints. Documented on the Netherlands page, true in every European market, and true at the till as well as on the invoice.
A document series you can name and register with an authority in advance
The counter beneath it is the right shape, which shortens the engineering. The registration step, the code that comes back from it, and the ability to run more than one series do not exist.
A ledger export in a prescribed schema
Our invoice export is seven header columns — no lines, no rates, no tax codes. A periodic-transmission obligation needs the detail behind the documents, and that export cannot carry it.
Records that are non-alterable in the sense a certification tests for
Deletion is refused, which is true and checkable and is a weaker property than the one being assessed. We have never been assessed against those requirements and we are not going to describe ourselves as meeting them.
A certificate, and a place on a public register
We hold none and we are on none. This is the only line in this list that is not work we can be commissioned to complete.
What to do about it, by shape
Workable
Your regime files documents after issue
You are running a normal evaluation and the usual questions apply — retries, a failure queue somebody looks at, and a report of documents carrying no reference. Ours is built for exactly this shape, for one authority, and adding a second is a build we would quote.
Workable
Your obligation is a periodic file in a prescribed schema
Cheaper than it sounds and more often failed than the flashy ones, because it needs line-level detail rather than document headers. Ask to see the export file itself, opened, on real data — not a description of it.
Difficult
Your regime authorises documents before they can be issued
Ask when and for which country the product was built, because resilience at the counter and a blocking fiscal step are opposite design goals. We would build this where a regime requires it, and we would want you to understand you are buying a till that stops when the authority does.
Stop here
Your regime certifies the software itself
Check the register before you check anything else, and check it for every vendor on the list rather than taking an answer. Choose your certified program first and fit the rest of your operations around it. We are not certified, we hold no connection today, and we would rather you knew that at the top of an evaluation than at the bottom of one.
Five questions with factual answers
Which shape is my obligation — filed, authorised, certified, or periodic?
What a straight answer sounds like
A named shape, with the rule it comes from. Put this to your adviser first; it is not a vendor question.
Why it matters
It decides whether you are comparing products or checking a register. Get it wrong and the entire evaluation is aimed at the wrong thing.
Are you on my country's register of certified programs?
What a straight answer sounds like
Yes with a number, or no. There is no third answer.
Why it matters
Where certification applies, this is the only question that matters and it is answerable in two minutes. Ours is no.
Show me a receipt printed while the authority is unreachable.
What a straight answer sounds like
A piece of paper, produced on the spot.
Why it matters
It reveals in one action whether the fiscal step is inside the transaction or after it, which is the distinction the whole page rests on.
Whose specification is the QR code on that document built to?
What a straight answer sounds like
An authority named. Ours is Kenya's.
Why it matters
A rendered QR looks identical whatever payload is inside it. A demonstration cannot distinguish a compliant code from a decorative one; only the specification can.
Can my document sequence skip, and has it ever?
What a straight answer sounds like
A mechanism described, and a date if it changed.
Why it matters
Every shape on this page assumes an unbroken sequence that belongs to you. Ours could skip until 6 August 2026 and we published that before anybody asked.
Three we would quote, one that improves every European market, and one that is not ours to schedule
Set out in this order deliberately, because the order is the honest one: the portable work first, the country-specific engineering second, and the thing that is not engineering at all last.
The document itself, which helps everywhere
Both tax identification numbers and the customer's address rendered on the printed document — all three are stored today and none of them prints. Alongside it, a ledger export carrying documents, lines, customers, products and tax codes instead of the seven header columns the invoice export emits now. Neither is Portuguese, or Dutch, or anything else; both improve every European market in the product at once.
Named series, declarable and registrable
A series you define, can run more than one of, and can register with an authority before use, with the returned code carried onto the document. The counter underneath is already locked, per organization and per year, so this is shorter than it looks.
Your authority's payload behind our QR
The renderer, the library and the place on the page are all in production; what is missing is a specification. That makes this a specification problem rather than a capability one, which is a genuinely different size of job and we would rather say so than let it be priced as though it were the hard part.
The certification submission — scoped, not scheduled
Where a regime certifies the program, we would scope and price the engineering a submission needs: the prescribed export schema, the record-integrity properties the requirements test for, the document code and the series behind it. Every other paragraph in this section of the site ends with terms we would agree with you. This one ends by saying which part is not ours to agree — the certificate is granted by an authority against its own requirements, and finishing the engineering is the beginning of an application rather than the end of one.
We will not tell you that certification is coming, and we will not tell you which shape your obligation takes. The first is decided by somebody else and the second by your statute and your adviser. A vendor who is confident about either is selling you a risk they have not priced.
Talk to us about your regimeThe verdict
A receipt rule can be an integration, an architecture or an accreditation, and only the first is a shortlist exercise. Find out which one you are under before you compare a single product, because the second cannot be configured into existence by a vendor built for the first, and the third is answered by a public register rather than by anything a demonstration can show you. We are built for filing, for one authority, and we are on no register. That is a limitation on a Tuesday in Lisbon and it is nothing at all in Nairobi — which is the entire point of asking the question in that order.
