Teams tend to treat e-invoicing as a formatting problem: new layout, new fields, done. In practice the failures cluster somewhere else entirely. They come from customer records missing a registration number, tax codes applied inconsistently across item groups, and credit notes that never referenced the invoice they adjusted.
Start with the customer master
Every invoice carries the buyer's details, so any gap in the customer record becomes a gap on the document. If the same customer exists three times with three different registration numbers, you will discover it one invoice at a time.
Deduplicate first, then decide who owns the master record afterwards. Without a named owner it drifts back within a quarter.
| Data set | Check before you switch | Why it bites later |
|---|---|---|
| Customers | Registration numbers, legal names, addresses complete and unique | Missing fields block or invalidate documents |
| Items | Tax treatment set per item, not per invoice | Manual overrides drift between users |
| Tax codes | One code per treatment, with exemptions defined | Duplicated codes make reporting unreliable |
| Documents | Numbering series continuous and unique | Gaps and duplicates are hard to explain |
| Credit notes | Every adjustment references its original invoice | Unlinked notes break the audit chain |
Put tax treatment on the item, not in people's heads
When tax is decided at typing time, two people will treat the same item differently and neither will be wrong on purpose. Setting treatment on the item and the customer removes the decision from the moment of data entry, which is where inconsistency enters.
Most reporting problems are not calculation problems. They are the same transaction coded two ways by two people on the same afternoon.
Decide the bilingual layout early
Arabic and English documents are not two templates. They are one document with both languages carrying the same data, and the layout decisions are easier to make before hundreds of documents exist than after.
Agree which fields appear in which language, and who signs off the final layout. Finance, sales and your auditor will each have a view.
Treat credit and debit notes as first-class documents
Adjustments are where audit chains break. A credit note that does not reference its original invoice is an orphan, and reconciling a month of orphans is slow work.
Worth agreeing before go-live
What is your policy on cancelling versus crediting? Different teams often assume different answers, and the assumption only surfaces when a customer disputes a charge.
A readiness sequence that works
- Deduplicate customers and complete their registration details.
- Set tax treatment on items and customer groups, then remove manual overrides.
- Consolidate tax codes so one treatment has one code.
- Fix numbering series and close any gaps.
- Link historical credit notes to their invoices where you can.
- Agree the bilingual layout with finance and your auditor.
- Run a period in parallel before you rely on the new output.
None of this requires new software. It requires a few weeks of unglamorous data work, done before the switch rather than during it.
