A fixed-price build is billed in three or four milestones across months. A support contract bills the same amount every month for a year. Hosting, domains and licences pass through your account and come back out on a client's invoice. Every one of those documents goes to another business, so every one is a standard tax invoice ZATCA must clear before you may send it — and you are paid sixty or ninety days later.
That last part is where it bites. VAT falls due at the earlier of the supply, the invoice or the payment, so the month you invoice a milestone is normally the month the tax is due, paid or not.
Milestones are separate invoices, not versions of one
A milestone is not a draft you top up later. If the contract bills 40 / 40 / 20, that is three complete tax invoices, each with its own number, its own ICV counter and the hash of the one before it. You cannot issue the first and amend it upward when the second stage is signed off: a transmitted invoice is immutable, and a change to an amount already issued is a credit or debit note against it.
Put the deliverable in the line description, not just "Phase 2" — in nine months that line is the only record of what the client paid for. When a long staged project counts as supplied turns on the contract wording and is worth ten minutes with an accountant; the invoice is not in doubt, since issuing it fixes the tax point.
A retainer is twelve documents a year
A support contract at a fixed monthly fee is not one recurring line. It is twelve invoices, each cleared on its own, each carrying the next counter value and the previous hash. Copying last month's invoice as a template is fine; what comes out is a new document with a new number.
Two things go wrong here. Reusing a number breaks the chain. And a signed invoice cannot be edited when the client asks for a change — a discount agreed late, a month billed in error — so that is a credit note (381) with a reason and a reference to the original, or a debit note (383) if the amount rises.
Pass-through costs, and what actually goes on the line
Hosting you buy and resell is your own supply: an ordinary taxable line at the price you charge, not the price you paid. A licence bought from a foreign vendor may fall under the reverse-charge treatment on your VAT return — a return question rather than an invoice-format one, with the rules published on zatca.gov.sa — and rebilling it is still an ordinary line.
The exception is buying in the client's name, with their money, and recharging the exact cost. That can be treated differently, and the honest answer here is: ask your accountant before the first invoice, not after the tenth.
Before the invoice, and after it
Two edges of your billing sit outside the invoice. Before it, the proposal: a scope and a price with a validity date, which becomes an invoice only when the client accepts. After it, the wait — cleared, sent, then nothing for two months. What helps there is a per-customer view of paid and outstanding, not more invoicing.
One habit worth fixing now: a standard invoice cannot go to the buyer before clearance returns. Sending the PDF today and clearing it tomorrow is the wrong order. If you are unsure which documents are standard and which simplified, that distinction is here.
The other question: "can you make our system issue ZATCA invoices?"
Sooner or later a client asks — an ERP, a booking system, something you built for them four years ago. The ticket is one line; the work is not. Price it from what it contains.
A direct integration contains, roughly in the order you meet it:
- A CSR and an OTP exchanged for a compliance certificate, per device.
- The compliance documents the Authority validates before it releases the production certificate.
- UBL 2.1 generation and XAdES signing.
- An
ICVcounter andPIHhash chain per device — state your application owns and must never lose. - Two transmission paths: clearance for standard invoices, reporting within 24 hours for simplified ones.
- The 135 documented validation rules — some of which reject the document, while the majority come back as warnings alongside an acceptance — each to be turned into something a user can act on.
- Certificate renewal, per device, forever.
You own that for as long as the client runs the system. Full account here.
Three ways to answer
| Build it in-house | Call an API | Partner API | |
|---|---|---|---|
| Best when | Strict data policy, or invoicing is your product | One client system to make compliant | Many client merchants |
| Certificates and renewals | Yours, per device, forever | Handled for you | Handled per merchant |
| Who enters the Fatoora OTP | You or the client, per device | The client, once | Each merchant, via an onboarding link |
| ICV / PIH chain state | Your database, your outage | Kept for you | Kept per merchant device |
| Signing and XML | Your code | You send invoice data | You send invoice data |
| Rejections | You map the codes | Official code plus its guide | Same, per merchant |
| What you maintain | The whole component | One request and its response | A key and an onboarding flow |
When building it in-house is right
Two cases. If a client's own policy forbids invoice data leaving their infrastructure, no third party is acceptable and you build or self-host — ask for that policy in writing before you price the work. And if invoicing is the product you sell rather than a feature inside it, owning every component is defensible, as long as everyone knows they are also buying the renewals.
Outside those two, ask what you want to be maintaining in three years.
What we provide
ZATCA Tools signs invoices with a compliant QR code, clears standard invoices and reports simplified ones within 24 hours, keeps the signed XML downloadable for six years, and shows a rejection with its official ZATCA code and a link to its guide. Quotations carry QT- numbering, a validity date and a link the client can accept, and an accepted quotation becomes an invoice draft. Receipt vouchers record payments against B2B invoices, so each reads paid, partially paid or unpaid, and the per-customer statement exports as CSV or PDF. Not an accounting system: no ledger, no journals, no inventory, no payroll.
For client work there is the REST API, the Partner API with its partner guide, a WHMCS module if your hosting billing runs there, and an n8n node for the rest. Free during the launch period, an account starts with 50 invoices and expands from there, and connecting takes one OTP from the Fatoora portal — start here, or send us the stack.