Invoicing Software: From Printing to Compliance

Many tools design a handsome document, place your logo on it and total the amounts. That is enough if an invoice were merely a notice to the customer.

It is not: an invoice is a statutory document with defined requirements, demanded at audit, and required to be kept for years.

The practical test is one question: can this invoice be verified without coming back to you? If the answer is no, what you hold is an internal document rather than a statutory invoice.

That is where the QR code comes in: it makes the invoice's basic data readable by any party directly. And a thermal receipt without a valid code is not a simplified invoice — it is a piece of paper.

Design aside, these are the fields you should see on a test invoice before committing to any software:

• The business tax number, clearly visible
• A QR code that actually scans with a phone — try it, do not assume it
• Date and time, not the date alone
• Line detail with quantities and prices
• Tax broken out, not merged into the total
• A sequential number that neither repeats nor breaks

The two invoice types differ: a simplified invoice is issued to an end consumer and printed in-store, while a full invoice is issued between businesses and includes the buyer's tax details and stricter requirements.

Many businesses need both — selling to individuals and to companies — and that is a direct question for the vendor: does it issue both types or only simplified ones?

Numbering looks like a formality and is among the most asked-about items at audit, because a gap in the sequence is a question: where is invoice 1047?

Tools that build documents by hand produce such gaps easily: a document created then cancelled, two copies with the same number from two machines, or numbering restarted at one each year with no declared rule.

What you need is for numbering to be the system's responsibility rather than the user's, and for cancellation to be a recorded operation — a credit note, for instance — rather than a deletion that leaves a hole.

This is precisely where an accounting system diverges from a design tool: the first knows an invoice is a financial event with consequences; the second knows it is a file.

The question nobody asks at purchase and everybody asks at audit: how do I retrieve an invoice issued two years ago?

Three common models and three outcomes:

• PDF files on a machine — works until the machine fails or whoever organised them leaves
• An online tool that retains for a limited period — read the term before subscribing, not after
• A system that stores and indexes — you search by number, customer or date and find it

Ask specifically about the retention period and about export: if you decide to move, do you leave with your invoices in full, and in what format? Exporting to PDF is not exporting data but pictures of it.

That question measures the vendor's confidence in their product, and deserves asking before signing.

A standalone invoicing tool's job ends at printing. Then yours begins: entering the same invoice into accounting, deducting the item from stock, and recording the receivable against the customer.

Three manual steps for one event — and that is precisely the source of the errors that surface at stocktake and at receivables reconciliation.

In an integrated system the invoice is an event rather than a document: it creates a journal entry, deducts stock, and records the receivable, in one motion.

In Snad the invoice is issued from sales, from the till or from a booking, the entry is created automatically, and the item is deducted at the moment of sale. ZATCA integration starts on the Basic plan — the free plan issues and books your invoices without direct platform integration, and a watermark remains on documents on the free and Basic plans.

And for anyone needing a quick document before deciding, Snad's free invoice generator runs in the browser with no sign-up.