How to write an invoice: every field, and why it is there
An invoice is three documents wearing one coat: a request for payment, a tax document, and the source record behind two entries in your ledger. Most advice covers the first and skips the other two — which is why so many invoices look perfectly fine and still come back.
The Fatouraty team
An invoice is three documents wearing one coat. It is a request for payment, so it has to be clear enough that a stranger in someone else's accounts department can act on it without calling you. It is a tax document, so a missing registration number or an unstated rate can cost your buyer their deduction — reason enough, on their side, to send it back. And it is the source record behind two entries in your own ledger, so what you write on it decides what your revenue figure says at month end. Most writing about invoicing covers the first job and skips the other two.
The fields, and what each one is for
There is no single template that fits every country, but the fields the region's tax authorities ask for overlap almost entirely, and each one exists for a practical reason rather than a formal one. Here they are, and what specifically breaks when one is missing:
| Field | What it does | What breaks without it |
|---|---|---|
| Seller name, address and tax registration number | Identifies who is charging, and makes the tax on it reclaimable | The buyer cannot deduct the tax, and the document may be rejected outright |
| Buyer name, and their tax number if a business | Ties the document to the party that will deduct it | The invoice cannot be matched to a purchase order or to a payment |
| A unique invoice number | The document's identity, and the anchor of the audit trail | Duplicates, gaps, and disputes with no way to settle them |
| Issue date, and supply date where different | Decides which tax period the invoice belongs to | Revenue and tax land in the wrong month |
| Description, quantity and unit price per line | What was actually sold, itemised | An unarbitrable dispute, and no basis for a partial credit note |
| Tax rate and tax amount per line | Different lines can carry different tax treatment | One blended rate that nobody can verify |
| Subtotal, total tax, and total payable | The three numbers the buyer's system reads | Manual re-keying, which is where the errors come from |
| Currency | Which currency the total is in, and at what rate it posts | A payment that arrives for an amount the invoice does not match |
| Payment terms and due date | When the amount is actually late | "Net 30" from an unstated date is not a due date |
| Payment details | How the money reaches you | A delay whose only cause was someone waiting for an account number |
Notice that half of these fields are not for you: they exist so the other side can post the invoice and reclaim its tax without asking you anything. An invoice that is enough for you and not enough for your buyer's accountant is an invoice that comes back, and it will have cost you a week of receivable age by then.
Numbering: the one field that tolerates no improvisation
The invoice number looks like an administrative detail. It is in fact the field the auditability of your whole ledger rests on. The rule the region's tax authorities converge on is the same in substance: an unbroken, non-repeating sequence, never reused and never retroactively renumbered. The reason is direct — a gap in the sequence is the first question an auditor asks, and a duplicate means your books contain revenue recorded either twice or once, with no way to tell which several months later.
- Do not number by date alone. "INV-2026-08" on four invoices in the same month is not a number, it is a category.
- Do not backfill gaps. If invoice 403 is cancelled, 403 stays cancelled forever and is never reassigned to something else.
- Do not correct a sent invoice by editing it. A sent document is cancelled with a credit note that names it by number, and a fresh one is issued under a new number.
- Do not let two people number by hand at the same time. That is the most common way two different invoices end up carrying the same number.
Tax is calculated on the line, not on the total
The most expensive mistake on hand-written invoices is multiplying the total by a single rate. It works as long as every line carries the same rate, and it collapses the moment you sell one exempt or zero-rated item alongside a standard-rated one — which happens more often than people expect: exports, medical services, some foodstuffs, and recharging a cost paid on a client's behalf are all treated differently from the line above them.
The difference is not cosmetic. A VAT return asks you to declare standard-rated sales separately from zero-rated and exempt sales, and those buckets cannot be recovered from an invoice carrying one blended rate. Anyone who records tax at the invoice level spends a day at the end of every period taking their own invoices apart by hand to fill the return in.
Rounding is the second trap here. Computing tax per line and adding the results can differ by a unit or two from computing it on the total, and that tiny gap is what makes the columns of your return refuse to add up to the total you declare. The answer is not picking the "better" method but applying one everywhere: Fatouraty computes per line, in integer minor units rather than floating-point decimals, so the sum of the lines equals the total every time, without exception.
An Arabic invoice, not a translated one
In Saudi Arabia specifically, Arabic on a tax invoice is a requirement rather than an option — another language may sit alongside it, but Arabic has to be there. In practice that is broader than translating words: the direction of the document itself changes, the quantity, price and tax columns reverse order, numerals may be written in Arabic-Indic form, and a long Arabic address field does not wrap the way its English counterpart does.
Which is why a tool that added Arabic later produces an Arabic invoice that looks acceptable on screen and breaks in print. Fatouraty is built the other way round: Arabic is the product's default language, page direction comes from logical layout properties rather than hardcoded left/right rules, and Arabic-Indic numerals are read on input as well as rendered on output. And the invoice document itself renders wholly in Arabic — the heading, the column labels, the name your country gives the tax registration number, and the customer's own Arabic name where one is on file — rather than an English layout with Arabic words dropped into it.
What happens after you send it
An invoice is not the end of a process but the start of one. Here is the full chain, and every step in it either happens automatically or becomes a manual task you forget:
- 1The invoice posts to the ledger: debit receivables, credit revenue, credit tax payable. That entry is what makes the invoice exist in accounting terms rather than as a PDF.
- 2It is submitted to the government e-invoicing platform where your country requires one, and its response is waited for — acceptance is not assumed just because the send succeeded.
- 3It enters the aged receivables report, ageing from its due date rather than its issue date.
- 4It lands in the correct tax period's bucket, classified by each line's treatment rather than by a single rate.
- 5When payment arrives it is matched against the invoice, closing the receivable partly or in full and moving cash in the ledger.
- 6And if a correction is needed, a credit note is issued referencing it by number — the original document is never edited.
Those six steps are the practical difference between writing an invoice and keeping books. A tool that produces a handsome PDF and leaves you to do the other five by hand has saved you nothing but the formatting.
Frequently asked questions
What is the minimum an invoice has to carry?
Seller name and tax number, buyer name, a unique invoice number, the issue date, itemised lines with quantities and prices, tax per line, the subtotal, total tax and total payable, and the currency. Individual countries add fields of their own — check your authority's rules before you settle on a template.
Can I edit an invoice after sending it?
No. A sent document is a record, and the correction is a credit note referencing it by number, followed by a fresh invoice if one is needed. In Fatouraty an invoice is editable only while it is a draft; once finalised and posted it cannot be edited, and voiding or crediting it is the route.
How should I number invoices if I work alone?
A plain ascending sequence is entirely sufficient, with a fixed prefix if you like. What matters is not the shape of the number but that it never breaks: no gaps, no duplicates, no reuse of a cancelled number, and no retroactive renumbering.
Why calculate tax per line rather than on the total?
Because lines inside one invoice can carry different treatments — standard-rated, zero-rated, exempt — and the VAT return asks for those buckets separately. An invoice with one blended rate cannot be taken apart into them except by hand.
Does the invoice have to be in Arabic?
It depends on the country. In Saudi Arabia Arabic is required on a tax invoice, with another language permitted alongside it. Elsewhere in the region the rules vary, and a bilingual invoice is a safe choice either way — check your own authority's text, because these rules do get updated.
What is the difference between the issue date and the supply date?
The issue date is the day the invoice was written; the supply date is the day the goods were delivered or the service performed. Where they differ, it is usually the supply date that determines which tax period the transaction belongs to — which is why it has to be stated explicitly when it differs.