Localisation and e-invoicing in ERPNext

After station seven your books are correct. This station asks something else entirely: are they acceptable to the tax authority in your country?

The question is not academic. A company that cannot issue an acceptable invoice cannot sell — however disciplined its system is internally.

Three layers everybody merges into one

More than half of all argument about “does this system support my country?” comes from folding three different things into a single question:

Layer	What it means	Who provides it
Language	Interface and report translation	The translation community
Accounting localisation	A local chart of accounts, taxes and report formats	A localisation app per country
Technical tax compliance	Signing the invoice and transmitting it to the authority’s platform	The layer you must ask about by name

The first two are configuration questions. The third is a legal question, and it is the only one with rejections, deadlines and fines in it. So when you evaluate any system, ask about the third by the explicit name of the government platform in your country — never about “Arabic support”.

Arabic in ERPNext, as a number rather than an impression

The Arabic translation exists, it is incomplete, and its own files say so. Measured directly against the project’s two repositories on 6 September 2026:

File	Total strings	Untranslated	Completeness
ERPNext translation	10,517	2,449	76.7%
Frappe framework translation	7,207	1,293	82.1%

Which is to say roughly one string in five reaches the user in English. That is not a defect in an open-source project, but it is a fact that belongs in a training estimate: a user who does not read English needs longer accompaniment, or an additional translation that has to be maintained across every upgrade.

A right-to-left interface raises a second question separate from translation: page layout itself. An open issue, number 28418, dated 10 November 2024 describes the navigation bar failing to anchor to the correct side in the Arabic view. Open it and read its state yourself before promising a client anything: the interface direction issue in the Frappe repository (read 6 September 2026).

The direct answer on e-invoicing

Here sits the most important difference between ERPNext and a system whose vendor ships tax integration inside its own repository:

Phase two integration with the Saudi Zakat, Tax and Customs Authority is not part of what the Frappe team ships. What is available comes from independent companies building an app on top of ERPNext — ERPGulf and Beveren Software among the most visible. The same holds for the UAE e-invoicing requirement.

That is less a negative remark than a correct location of responsibility. Read the difference:

The question	When the vendor ships integration	When a third party ships it
Who updates when the specification changes?	The vendor, inside the release	The third party, on their own schedule
What does it cost?	Usually inside the subscription	A separate additional line
Who do you go to when an invoice is rejected?	One party	Two, who may refer you to each other
What if the provider stops?	Does not arise	A question to ask before signing

So the rule you leave holding: do not ask “does ERPNext support e-invoicing?” — ask “which app specifically, who maintains it, at what price, and how fast do they respond when the specification changes?” Anyone who puts the question in that form in a system-selection meeting saves their company a year of surprises.

Note a second separation, this one about services rather than software: the developing company does not deliver implementation itself, and implementation runs through a partner network of more than two hundred firms. What is sold as paid support is a product warranty covering defect repair in the software, and its page states explicitly that it does not include functional support. The detail is in the ERPNext guide.

Why cancel-and-amend turns out to be the feature

At station two the three states looked like an irritating constraint: draft, submitted, cancelled — submission a one-way door, and correction by cancellation plus an amended copy. At station five the credit note became the only route to correcting a submitted invoice.

The reason surfaces now. Every e-invoicing regime in the world imposes the same rule: an invoice signed and transmitted to a tax authority is neither edited nor deleted, and the correction is a separate document linked to it.

Which means a product that permits editing a submitted invoice is a product that will have to be constrained later to work with any tax specification at all. ERPNext is constrained by design already.

There is a practical inversion here worth writing in your notebook: the discipline you complained about in the first week is the requirement you receive pre-built in the sixth month.

Seven questions before any promise

This list holds for any system and any country, and it is the most useful thing you take from this station:

1. What exactly is the government platform called, and what phase is it in now?
2. Which app provides the integration, and who owns it?
3. Is that app open source or closed, and under which licence?
4. When was it last updated? A compliance app with no update in six months is a risk indicator.
5. Does it work with the ERPNext version you will run? Version compatibility is the first break point.
6. Who signs the digital certificate and who holds its key?
7. What is the emergency procedure when the platform rejects an invoice on a working day?

Six and seven are the two nobody asks and everybody pays for. A single rejected invoice on a closing day stops delivery, and a team that never wrote its procedure invents one under pressure.

The same requirements independent of any system are set out in ZATCA phase two and UAE e-invoicing.

What you actually do at this station

You will not build a real integration in a training environment, and nobody expects you to. What is required is that you build the structure any integration will consume, which is nearly identical across specifications:

• The company’s tax registration number and its full address in separate fields, not one block of text.
• The customer’s tax registration number on the party card — the field flagged at station three.
• A separation between business invoices and consumer invoices, because the specifications differ on what each must contain.
• An explicit per-line tax structure, since every specification wants tax itemised rather than aggregated.
• An unbroken numbering sequence, because a gap in invoice numbering is an inspection question before it is a system question.

Then issue a complete invoice and read it as an inspector would: does it carry every mandatory item, or is there a field you assume will be filled in later?

The commonest localisation error

Setting tax at item level instead of on a tax template. It works in the demonstration, then collapses the moment the same item is sold to an exempt customer and a taxable one, or the rate changes by decree.

The rule: tax is a property of a relationship between two parties on a date, not a property of a thing. Understand that sentence and you configure tax once; miss it and you reconfigure it on every item at every change.

The acceptance test for this station

1. Write one page answering the seven questions above for your own country. That page is a portfolio piece, and it is the closest thing you will write to real consulting work.
2. Fill in the tax data for the company and for two customers: one a business with a registration number, one an individual without.
3. Issue two invoices — one of each type — and compare what appears on them.
4. Open the Arabic translation file in the repository and verify the figures above yourself. Never repeat a number you have not read.
5. Issue a credit note and explain in one sentence why every e-invoicing regime imposes that ordering.

What comes next

You know the limits of what the product ships. The next station asks what to do when what shipped is not enough — the dividing line between customisation without code and customisation with it, and why in most requests the correct answer is to write nothing at all.