Guides · Saudi Arabia
ZATCA e-invoicing for meal-plan businesses in Saudi Arabia
Saudi e-invoicing is the clearest example in the region of tax administration becoming a data format rather than a document. For a subscription food business that changes what an invoice record has to contain, and the change is far cheaper made early than retrofitted.
Why this matters more for subscriptions than for one-off sales
A restaurant issues an invoice per transaction and each one stands alone. A meal-plan business issues a recurring stream of invoices to the same customers, month after month, each one connected to a set of deliveries that may include pauses, skips and failed drops.
That volume and that linkage are what make retrofitting painful. Adding a required field to a system that has issued four hundred invoices means four hundred historic records that lack it, and any hash-chain requirement means the chain has a hole where the field was introduced.
The practical implication is that the invoice record should carry the structure before you are obliged to use it. Storing fields you do not yet transmit costs almost nothing; adding them later is a migration.
What an invoice record needs to carry
These are structural fields rather than presentation. Getting them into the record early is the whole point.
Seller and buyer tax registration
Held against the tenant and the customer rather than typed per document, so they cannot drift between invoices.
A QR payload
Encoding seller name, VAT number, timestamp, total including VAT, and VAT amount — the five values a compliant scanner reads.
The VAT rate as data
Not baked into a template. Rates differ across the Gulf, and a business serving more than one market needs the rate stored per invoice rather than assumed.
An invoice hash
A cryptographic digest of the invoice content, so a document can be shown to be unaltered.
A link to the previous invoice
Each invoice referencing its predecessor’s hash, forming a chain. This is the field most often missed and the hardest to add retroactively.
The phase distinction is the part people get wrong
Saudi e-invoicing arrived in stages, and conflating them causes a lot of confused vendor conversations. The first stage is about generating and storing structured invoices with a compliant QR. The second is about integration — onboarding cryptographic credentials, signing invoices in a mandated XML form, and submitting or clearing them through the tax authority’s platform.
These are very different engineering problems. Producing a correct QR is a contained piece of work. Integrating with a clearance platform is an ongoing relationship with an external system, including credential lifecycle and failure handling when submission does not succeed.
When a vendor says they "support ZATCA", the useful question is which of those two they mean, and to ask to see it rather than take the claim.
Where Mealroh actually sits, precisely
The invoice record carries the structural fields described above: seller and buyer VAT numbers, the QR payload, VAT rate stored per invoice, an invoice hash, and the previous invoice’s hash forming a chain. The Phase-1 QR is generated as a TLV-encoded payload of the five mandatory tags.
What Mealroh does not do is Phase-2 clearance. There is no cryptographic credential onboarding, no mandated XML signing, and no submission or clearance flow with the tax authority’s platform. If your business is in scope for that, you need something that performs it, and Mealroh is not currently that thing.
We are being this specific deliberately. "ZATCA-ready" is a phrase that gets used to mean anything from a QR on a PDF to full clearance integration, and a meal business making a compliance decision deserves to know which one it is buying.
What to do about it
Confirm your own obligations with an accountant rather than a software vendor, including whether and when your business falls into scope. Requirements have been phased by taxpayer size, and neither we nor any vendor can tell you where you sit.
Then, whatever the answer, make sure the invoice record holds the structural fields. That is true regardless of your current obligation and it is the part that becomes expensive to fix later.
If you are already in scope for clearance, treat the operational system and the clearance integration as two components. The system that knows what was delivered and what is owed does not have to be the system that talks to the tax platform, and expecting one product to do both is how people end up with neither done well.
Common questions
- What is the difference between the two ZATCA phases?
- The first is about generating and storing structured invoices with a compliant QR code. The second adds integration — credential onboarding, mandated XML signing, and submitting or clearing invoices through the tax authority’s platform. They are very different engineering problems.
- Does Mealroh support ZATCA?
- It carries the structural fields — seller and buyer VAT numbers, the Phase-1 five-tag QR payload, VAT rate per invoice, an invoice hash and the previous invoice’s hash. It does not do Phase-2 clearance: no credential onboarding, no XML signing, no submission to the tax platform.
- Why does the invoice hash chain matter?
- It links each invoice to its predecessor so the sequence can be shown to be unaltered. It is also the field hardest to add retroactively, because introducing it later leaves a gap where the chain begins.
- Should I add these fields before I am obliged to?
- Almost certainly. Storing fields you do not yet transmit costs very little, whereas adding them to a system that has already issued hundreds of invoices is a migration with historic records that cannot be completed.
- Can a software vendor tell me whether I am in scope?
- No, and be wary of one that tries. Scope has been phased by taxpayer size and the question belongs with an accountant who knows your registration and turnover.
See how invoicing derives from deliveries
Mealroh generates invoices from the same records that drove production and delivery, so the document agrees with what physically happened. The product pages show it against a demonstration kitchen.
Related reading
- GuidesBilling a meal plan that keeps changingBilling here is harder than a flat subscription because the thing being billed for is physical and intermittent. The invoice has to agree with a stack of boxes that may or may not have arrived.
- SolutionsInvoicing for meal-plan businessesAn invoice from a meal-plan kitchen has to agree with something physical — a set of boxes that did or did not arrive — which makes it harder to get right than a simple recurring charge.
- SolutionsMeal delivery software for UAE meal-plan businessesA kitchen serving more than one emirate is running one production operation against several delivery realities. The software has to keep that manageable without turning each emirate into a separate business.
- SolutionsMeal delivery software for finance and adminFinance in a meal-plan business spends most of its time on one question: does the amount we billed match what the customer actually received? Everything else follows from getting that right.