A retailer issuing invoices with broken right-to-left layout may fail to meet the Arabic-content requirement, so this is a compliance question and not only a cosmetic one.

ZATCA requires Arabic on tax invoices, and in practice most Riyadh businesses issue bilingual documents so that Arabic satisfies the regulator while English serves international suppliers and customers. Getting the bilingual layout right is a configuration exercise in the ERP, and it interacts directly with Phase 1 field requirements and QR code placement.

The item description problem

The most common gap is item master data. A system can render every label and heading in Arabic and still produce an invoice with English-only line item descriptions. This happens when nobody populated Arabic descriptions in the product master. Fixing this is a data exercise across potentially thousands of items. This is why we assess item master completeness before agreeing an Arabic invoice go-live date.

Layout and rendering

Right-to-left layout involves more than mirroring. Numbers, currency amounts and Latin-script product codes remain left-to-right within an RTL document, and mixed-direction text needs correct bidirectional handling or it displays in a scrambled order. Font selection matters too, because the font must render Arabic correctly in the PDF output and in print, and some default report fonts do not.

Names, addresses and legal identifiers

The seller's legal name in Arabic must match the commercial registration exactly, and the same applies to the buyer's name on B2B invoices. Addresses follow the Saudi national address format with building number, street, district, city and postal code. These fields are easy to check against the commercial registration, so mismatches stand out in an audit.

A hypothetical example

Consider a supplier whose Arabic invoice template renders correctly but prints a shortened trading name instead of the full Arabic name on the commercial registration. The effect on past invoices would need to be assessed with the company's tax adviser.

Testing before rollout

We test the configured template against each invoice variant the business issues: long item descriptions that wrap, multi-page invoices, credit notes, foreign currency, and zero-rated and exempt lines. We also test printed output on the devices in use. A template that renders correctly in a PDF preview can still break on a thermal printer. This connects to broader Arabic reporting configuration across the system.

Populating the item master efficiently

Translating thousands of item descriptions is the part many teams dread, and sequencing makes it manageable. We prioritize by transaction volume so the items on most invoices are correct first, and we use consistent terminology across product families instead of translating line by line. We also add a validation rule that stops new items being created without an Arabic description, so the backlog does not rebuild. The same master data discipline underpins Arabic financial statements.

Reviewing the template with the people who use it

A template that looks correct to a consultant may not work for the staff member who issues invoices all day. The final layout should be reviewed with the actual billing team and, where possible, a sample of customers. Small issues, such as an invoice number that is too small on the printed copy or an important field below the fold, are easier to fix before launch.