AWRA OpsHub Search

Arabic, French & the Localization Nobody Tests

Every vendor selling into Egypt, Morocco, Tunisia or Algeria says they are localized. Almost none are asked which layer they mean. Here are the seven layers, the order in which they actually bite, and an unusually blunt account of where our own product stops.

Africa Business Guides Washingtone Aura 12 min read

"Is it localized for Egypt?" is a reasonable question with a useless answer, because localization is not a property. It is a stack of at least seven separate things, each built by different people, each failing differently, and a vendor can honestly say yes while meaning only the first one.

This post is the field guide we wish existed when we started answering questions from Cairo and Casablanca. It applies to any vendor you are evaluating, including us — and the section where we score ourselves is the one worth reading closely, because we fail several of these layers outright.

Nothing here is tax or legal advice. Confirm every fiscal obligation with the relevant authority — the Egyptian Tax Authority, the Direction Générale des Impôts, or your own adviser.

The seven layers

They are listed in the order most buyers discover them, which is almost exactly the reverse of the order in which they hurt. Currency gets checked in the first demo. Working week gets discovered in month four, by an HR administrator, in an email that begins "quick question".

What "localized" can mean, layer by layer

1 · Currency

Does the system think in Egyptian pounds or Moroccan dirhams natively, or is it converting from something else at display time? The easiest layer, the one every vendor passes, and the one buyers spend the most demo time on.

Built in

2 · Tax rate and treatment

A rate is trivial. What matters is whether net, tax and gross are separated at the line on purchases as well as sales, and whether additional components can carry their own rates and effective dates. Ask who maintains those definitions when they change — you or the vendor.

Configurable

3 · Fiscal transmission

Electronic invoicing, e-receipts, clearance, filing. This is where the word "compliant" does the most work and carries the least meaning. It is also the only layer on this list where, in some markets, getting it wrong is not merely inconvenient.

Not built

4 · Statutory payroll

Income tax withholding, social insurance, the declarations that follow. Every market on the continent does this differently, and a maintained engine for one country tells you nothing about the next.

Not built

5 · Interface language and script

What the storekeeper actually reads. Arabic requires right-to-left layout, not merely translated strings — the whole interface mirrors. French is left-to-right but no less real for the person keying transactions in Rabat. This layer is almost never in the RFP and is frequently what decides whether the system gets used.

Not built

6 · Document output

The invoice your customer receives, the purchase order your supplier reads, the delivery note the driver hands over. These leave your building and are read by people who never see your interface — so they can need a different language from the one your staff work in.

Not built

7 · Calendar and working week

Egypt's weekend is generally Friday and Saturday. Morocco's is generally Saturday and Sunday. Any system that computes working days on a hardcoded Saturday–Sunday assumption is quietly wrong in one of those two countries, every single week. Ours is now set per organization — but read the detail further down, because not every clock in the product reads it.

Configurable

The statuses above are our own, for Egypt and Morocco specifically, and they are explained in detail further down. Use the same seven rows on every vendor you shortlist and you will get more signal in ten minutes than a feature comparison gives you in a fortnight.

Seven stacked localization layers from currency at the top to calendar at the bottom, showing that buyers inspect the top layers in the demo while the lower layers are the ones that surface after go-live
Attention runs top-down. Consequences run bottom-up. The layers nobody demos are the ones an administrator emails you about in month four.

Where we stand, market by market

Here is our own scoring against those layers, with Kenya included as the reference — because the honest way to describe a localized product is to show the one market where the deep layers are genuinely built and let the contrast speak.

AWRA OpsHub by localization layer

Layer Kenya Egypt Morocco
Local currency as a built-in preset Yes Yes Yes
A national VAT rate shipped as a preset Yes Yes Yes
Additional tax components with dates and treatment Partly — configurable by you Partly — configurable by you Partly — configurable by you
Fiscal e-invoicing / clearance integration Yes No No
Maintained statutory payroll Yes No No
Interface in the local working language Yes No No
Right-to-left interface layout No No No
Documents produced in the local language Yes No No
Working week other than Saturday–Sunday Yes Yes Yes

Built and maintained Configurable by you, not maintained by us Not built

Kenya scores "yes" on interface language because the working language of Kenyan business is English, not because we translated anything — which is itself a useful illustration of how soft this vocabulary is. The one "no" and one "part" in the Kenya column are marks we would rather you saw than discovered — even our strongest market is not a clean sweep.

Layer five, in plain terms

Since it is the layer that most often decides adoption, it deserves more than a mark in a grid. AWRA OpsHub's interface is in English. There is no Arabic interface, no French interface, and no right-to-left layout. We do not ship translation files, and the product is not internationalized in the sense a developer would mean — this is not a switch waiting to be flipped.

For some organizations that is genuinely irrelevant. A Cairo trading company whose entire back office works in English, or a Casablanca group whose finance team is comfortable in English, will not notice. For others it is disqualifying, and it should be — a warehouse supervisor who reads Arabic and is asked to key stock movements into an English interface will either be slow, wrong, or quietly go back to paper. All three outcomes cost more than the software.

The interface language is not a preference. It is the difference between a system your storekeeper uses and a system your storekeeper is entered into by somebody else, the next morning, from a notebook.

So the test is not "do we mind English". It is: who touches this system daily, and in which language do they think when they are busy? Answer that honestly and layer five either disappears as a concern or ends the conversation. Both are useful outcomes, and both are cheaper now than in month three.

Layer seven, and why it is on this list

The working week looks like a triviality and is included precisely because it is the kind of thing that never appears in an evaluation and then generates a year of small, irritating wrongness.

Systems that calculate working days need to know which days do not count. Ours used to assume Saturday and Sunday, in code — correct in Morocco, quietly wrong in Egypt every single week, in the same direction, forever. This page said so plainly for as long as it was true. It is now a per-organization setting: tick Friday and Saturday and leave-day arithmetic and the attendance present-rate average follow the actual week.

Two boundaries are worth knowing before you treat the layer as closed. Workflow due dates and escalation read a separate business calendar, so an organization that sets the HR week and forgets that one will get two different answers to the same question. And elapsed-time clocks — ticket SLA response and resolution targets, receivables and stock ageing — count calendar time rather than working days, which means a Thursday-afternoon ticket in Cairo keeps ageing across the weekend. That is defensible for support commitments and simply wrong-feeling for ageing; we would rather name it than let an administrator discover it in month four.

Ask every vendor the exact question anyway — "which days does your system treat as the weekend, can we change it, and does every calculation read the same setting?" The third clause is the one that separates a setting from a solved problem.

Questions that expose the layer being answered

Four questions, and what the answers really tell you

Is your product localized for Egypt?

What you will hear

Yes — usually with currency and VAT mentioned as evidence.

How to read it

That is layers one and two, which is where every vendor is strong. Immediately follow with layers three through seven, one at a time. A vendor who answers all seven crisply has thought about this market; one who conflates them has sold into it without thinking about it.

Can the interface be shown in Arabic?

What you will hear

Yes, or "it can be translated", or a reference to browser translation.

How to read it

Browser translation is not localization — it breaks on dynamic content and does nothing for layout direction. Ask to see a screen in Arabic, live. Then ask whether the layout mirrors, because translated strings in a left-to-right layout are their own kind of unusable.

What language do the documents come out in?

What you will hear

Same answer as the interface, usually given without pausing.

How to read it

These are genuinely separate layers and the answer differs more often than vendors realise. Your staff and your customers are different audiences, and only one of them ever sees the interface.

Which days does the system treat as non-working, and does every calculation read the same answer?

What you will hear

A pause. Then Saturday and Sunday, and often an offer to check.

How to read it

The pause is the answer. It means nobody has been asked before, which means this product has not been operated in Egypt or the Gulf. The second half of the question is the sharper one: a vendor can have a weekend setting and still have three modules ignoring it. Ask which calculations read it and which run on calendar time.

How to use this

  • Score every shortlisted vendor on all seven layers, in writing. Verbal answers to layered questions collapse into the easiest layer within a week of the meeting.
  • Decide which layers are deal-breakers before you hear any answers. Otherwise you will rationalise whichever layers your favourite vendor happens to fail.
  • Separate "not built" from "not built by them". A vendor who says "we do not do fiscal transmission, and here is how our customers handle it" is more useful than one who is vague about doing it.
  • Ask who maintains each layer after purchase. Configurable and maintained are opposites dressed as synonyms — configurable means you own the upkeep.
  • Test layer five with the actual person. Not the finance manager who speaks four languages. The storekeeper, on their phone, at the end of a shift.
  • Assume the layers you did not ask about are unbuilt. In this category, silence is never a yes.

Where to go next

The country-specific versions of this argument are in the Egypt buyer's guide and the Morocco buyer's guide. Layer three in Egypt is serious enough to have its own post — ETA e-invoicing and what it means for your operations system — and the currency layer, which behaves completely differently in the two countries, is in multi-currency operations in Egypt and Morocco.

Our take

Stop asking whether a product is localized and start asking which of the seven layers it covers, who maintains each one, and in what language the person doing the work will read the screen. Run that on us and we build one outright, make two configurable, and fail four — which for some North African organizations makes us a sensible operations layer alongside local specialists, and for others makes us the wrong purchase. We would rather you reached the second conclusion in a demo than a year in.

This is scope, not a ceiling

What is not built for Egypt today can still be built for you

Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Egypt. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If ETA e-invoicing, an Arabic right-to-left interface, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.

ETA e-invoicing and e-receipts

Document structuring to the prescribed format and submission against the Authority's interface, including the part vendors skip — rejection handling, resubmission, and a daily report of sales with no registration identifier.

Arabic interface, banks and payments

Arabic text with right-to-left layout and bilingual document templates, plus bank feeds and local payment gateways wired into the Payments Register.

Payroll and statutory returns

An Egyptian payroll engine with income tax bands and social insurance contributions, producing schedules in the layout your filing body expects rather than a spreadsheet rebuilt each month.

Systems you already run

The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.

How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.

Tell us what you need integrated

Score us on all seven layers

Bring the list. We will answer each one on the record, including the four we fail, and tell you which North African organizations we are genuinely a good fit for.

See the honest position for Egypt

Frequently asked questions

Does AWRA OpsHub have an Arabic interface?

No. The interface is in English only. There is no Arabic interface, no French interface and no right-to-left layout, and the product does not ship translation files — this is not a setting waiting to be enabled. For organizations whose back office works in English this is a non-issue; for organizations where warehouse, field or branch staff work in Arabic or French it is likely to be disqualifying, and we would rather say so now than discover it together at go-live.

Do you support right-to-left layouts?

No. Right-to-left is a layout property rather than a translation one — the entire interface mirrors, not just the text — and we have not built it. Be sceptical of any vendor who offers Arabic strings without RTL layout, because translated text inside a left-to-right interface is its own category of unusable and is often presented as full Arabic support.

What language do invoices and purchase orders come out in?

English. Documents that leave your building — invoices, purchase orders, delivery notes — are produced in the same language as the interface, and we do not ship Arabic or French document templates. This is a separate layer from the interface and worth checking separately with every vendor, because your customers and suppliers are a different audience from your staff.

Which days does the system treat as the weekend?

Whichever days you set. Non-working days are configured per organization — tick Friday and Saturday for Egypt, Saturday and Sunday for Morocco — and leave-day arithmetic and the attendance present-rate average exclude those days plus your configured public holidays. This was a hardcoded Saturday–Sunday assumption until recently and this page described it as a compromise for as long as it was one. Two limits remain: workflow due dates read a separate business calendar that must be set to match, and elapsed-time clocks such as ticket SLA targets and ageing buckets count calendar days rather than working days.

Do you handle Egyptian or Moroccan electronic invoicing?

No. Our only fiscal e-invoicing integration is Kenya's eTIMS and it is Kenya-only. Egypt operates an electronic invoicing regime administered by the Egyptian Tax Authority with obligations that depend on your taxpayer category, and Morocco has been moving in the same direction — confirm your own obligation, its scope and its timing with the relevant authority or your adviser. Where such an obligation applies to you, you need a compliant solution for it and it will not be us.

So when does AWRA actually make sense in North Africa?

When your working language is English or your back-office team is comfortable in it, when your fiscal transmission and payroll obligations are already handled by local specialists or software, and when the problem you are solving is the operations layer — stock across locations, procurement with enforced approvals, asset custody, project and donor attribution, landed cost on imports. That is a real and reasonably common shape, particularly for exporters, international NGOs and groups operating across several countries. Outside it, buy locally.

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center