Arabic-first, not translated: what it means for e-invoices
Most invoicing tools were designed in English and taught Arabic later. On a Saudi tax document — where Arabic fields are the legal record — that difference shows up in broken layout, mangled direction, and fields that don't survive round-trips.
Where bolt-on Arabic fails
A translation layer swaps labels; it doesn't change how the software thinks. So Arabic seller names render backwards inside mixed text, right-to-left layout fights left-to-right forms, and the one language the regulation actually cares about becomes the least reliable part of the invoice.
Arabic-first by design
In Signet this means
- RTL and bilingual throughout — the interface and the documents, not a translated skin over an English tool.
- Arabic fields treated as first-class data — entered, stored and rendered without round-trip damage.
- The same standard across the stack, from the free QR decoder to the Phase-2 bridge.
It runs in the family
Signet shares its foundation with the rest of the Zelicra suite serving the GCC — Arbiter issues Hijri-dated Arabic invoices for Kuwait, and the platform standard is bilingual EN/AR from the schema up. Arabic is the design language, not an add-on.
See it in the free tool
The Fatoora QR decoder reads the Arabic seller fields out of any Saudi invoice QR and shows them correctly — paste a code and look.