A French-Language Business Buying English-Language Software
Our interface is English. Yours is not. That is two separate problems — a staffing problem inside the building and a document problem outside it — and only one of them has an honest workaround.
Every vendor selling international software into a Francophone market has a practised answer to the language question. It is usually some combination of "the interface is intuitive", "your team will adapt quickly" and "French is on the roadmap". We have used versions of the first two ourselves and they are not exactly false, which is what makes them unhelpful.
This post replaces them with something more useful: a way of working out, before you buy anything, whether an English-language system is survivable in your specific organization. Sometimes the answer is yes and the objection is overstated. Often it is no, and the honest thing is to say so early.
Our position, stated once so it is not in doubt: the interface is English only, there are no translation files in the product, there is no setting waiting to be enabled, and everything the system prints is in English. This is not a limitation we are managing toward a fix.
Two problems, not one
The reason the standard answers are unsatisfying is that they address one problem while the buyer is worrying about two, and the two have completely different characters.
Inside the building, it is a staffing question. Who has to touch the system, and can you reliably employ people in those roles who work comfortably in English — not once, but continuously, through turnover, at every site, including the depot upcountry? This is a question about your organization, and its answer is knowable in advance.
Outside the building, it is a document question. Your invoices go to customers. Your purchase orders go to suppliers. Your delivery notes travel with goods. These leave your control and land in front of people who did not choose your software and have no obligation to accommodate it. This question is not about your organization at all, and no amount of internal capability solves it.
Internal language is a hiring constraint you can plan around. External language is a commercial fact you cannot.
Inside: which roles can you actually staff?
Work through your own organization role by role rather than answering in general. The pattern below is what we typically see, and the variance between organizations is large — which is exactly why a general answer is useless.
Can this role work in an English-language system?
| Who touches the system | Typically viable | Depends on the organization | Usually not |
|---|---|---|---|
| Finance and management — reports, approvals, analysis | Yes | No | No |
| Procurement officers — requisitions, orders, supplier records | Yes | No | No |
| Programme and project staff in internationally funded organizations | Yes | No | No |
| Head-office administrators — a small, stable, trained group | No | Yes | No |
| Warehouse supervisors — transfers, receipts, counts | No | Yes | No |
| Branch or shop managers | No | Yes | No |
| Counter and till staff, often with high turnover | No | No | Yes |
| Depot storekeepers upcountry, hired locally, trained on site | No | No | Yes |
| Drivers and field staff capturing anything on a device | No | No | Yes |
Built and maintained Configurable by you, not maintained by us Not built
Read the bottom three rows carefully, because they are the ones that decide this. A great many organizations can staff the top of the list comfortably and cannot staff the bottom of it at all — and the bottom of the list is where the data actually originates. A system nobody at the point of capture can use does not produce reliable records, however capable head office is.
There is a second-order effect worth naming. Even where a role is viable today because the current post-holder happens to be comfortable in English, you have narrowed the pool from which you can replace them. In a market where a storekeeper is hired locally on short notice, that constraint is not theoretical — it is the reason the role is vacant for six weeks next year.
The test that settles it
Do not evaluate this at head office with your best people. Take the demo to the site with the least-trained staff and the highest turnover, and ask someone who works there to complete a real task — receive a delivery, count a shelf, ring up a sale — without help. Watch what happens. That fifteen minutes is worth more than any amount of discussion about how intuitive an interface is, and it is the test that most often ends our own sales conversations.
Outside: what leaves the building
The document question is simpler to state and harder to work around, because it is not about capability. It is about what your counterparties expect and, in some cases, what they are entitled to.
An invoice in English arriving at a Senegalese or Ivorian customer is not incomprehensible — the amounts and the line descriptions carry most of the meaning. But it reads as foreign, it may sit awkwardly with a customer's own accounting process, and where a document has any administrative standing, the language of it stops being a matter of style. Confirm with your expert-comptable what the position is for the documents you issue; do not take a software vendor's view on it, including ours.
The honest options, then, and none of them are ideal.
Option one
Accept English documents
Workable when your counterparties are international — export customers, foreign suppliers, donor-funded programmes. Not workable for a domestic retail or distribution business whose customers and suppliers are local. Be honest about which you are, and ask two or three actual customers rather than guessing.
Option two
Produce customer-facing documents elsewhere
Issue invoices from your local accounting package or your expert-comptable's system, while the operations system runs everything internal. This is a genuine arrangement and many organizations already work this way. The cost is a reconciliation point — two systems now know about the same sale, and you must decide which one is authoritative and check that they agree.
Option three
Buy locally for the whole thing
If your business is domestic, your counterparties are local, and your staff work in French, this is very likely the correct answer. We say so on first calls regularly. A capable local vendor in your language will serve you better than we will, and no operational feature we have compensates for a system your team cannot use.
Workarounds that hold, and workarounds that do not
Some mitigations are real. Others are the kind that survive a demo and fail in month four. Being specific about which is which is more useful than a general reassurance.
These genuinely help
- Naming things in French inside English fields. Item names, location names, customer names, project names and cost centres are free text — so the data can be entirely in French even though the labels are not. In practice this covers a surprising share of what a daily user reads.
- A short bilingual card at each workstation. Fifteen terms cover most day-to-day use. Laminated, at the counter, in the warehouse. Unglamorous and effective.
- Restricting roles to narrow screens. A storekeeper who only ever sees a receive screen has perhaps eight English words to learn rather than an application. Tight permissions are a language mitigation as well as a control.
- Training in French on an English system. Entirely possible, and the trainer matters more than the interface. Insist that implementation and training happen in your team's language even if the software is not.
- Keeping documents that leave the building out of the system. See option two above. A real arrangement with a real cost, honestly priced.
These do not
- "It is intuitive, they will pick it up." True for motivated head-office users. Not true at a counter with turnover, and the failure is silent — people keep using the system and the data quietly degrades.
- Browser auto-translation. Breaks layouts, mistranslates domain terms inconsistently, and produces a different vocabulary for the same button on different days. It also translates data, not just labels, which is worse than leaving it alone.
- "French is on the roadmap." Ask for a date, a scope and a written commitment. Absent all three, treat it as a no. We do not make this claim at all, which is at least unambiguous.
- Editing the documents after export. Someone will do this for a fortnight and then stop, and the version your customer receives will diverge from the version in the system. Manual post-processing of outgoing documents is a control failure waiting to be discovered.
- One bilingual person who handles everything awkward. This is not a mitigation, it is a single point of failure with a notice period.
Questions to put to any international vendor
"Show me an invoice and a delivery note, printed, in French, right now."
What you will hear
Either a French document on screen, or a straight no.
How to read it
This is the fastest way to establish the truth. "It can be customised" means somebody will pay to build it and maintain it, and that somebody is you. Our answer is a straight no.
"Is there a language file in the product today?"
What you will hear
Yes with a demonstration, or no.
How to read it
A product built for translation has the machinery even if French is incomplete. A product with no machinery at all is years from French, whatever the roadmap says. We have no machinery.
"Which of your existing clients work in French, and may I speak to one?"
What you will hear
A name, or an admission that there are none in this situation.
How to read it
The best possible research you can do. Fifteen minutes with a comparable client tells you more than any demo, and a vendor who cannot produce one has not solved this before.
"Will implementation and training be delivered in French?"
What you will hear
A clear yes with named people, or a clear no.
How to read it
This is separable from the interface language and it matters enormously. A vendor who cannot train in your language is asking you to absorb the whole cost of the mismatch.
"What happens when our storekeeper leaves?"
What you will hear
An honest engagement with the replacement problem.
How to read it
Any vendor who has not thought about turnover at the point of capture is selling to head office and has not considered where your data actually comes from.
Where we honestly fit
What AWRA OpsHub does today
- All data you enter can be in French — item names, descriptions, customers, suppliers, locations, projects, cost centres, notes and justifications are free text and we do nothing to them.
- Documents and photographs attached to transactions are yours, in whatever language they arrived in, unaltered.
- Permissions can be narrowed so a given role sees very few screens, which materially reduces how much interface anyone has to learn.
- Implementation and training can be arranged in French through the people delivering your rollout, even though the product is not.
- The CFA franc, local VAT presets and local date handling all work regardless of interface language — localization of the data layer is unrelated to localization of the interface.
What it does not do
- A French interface. There are no translation files in the product and no setting to enable one. This is not a partially completed feature.
- French output on any printed document — invoices, purchase orders, delivery notes, receipts, payslips are all English.
- Right-to-left or any alternative script support, which is relevant if your organization also operates in Arabic.
- French-language in-product help, documentation or notification emails.
- A commitment to any of the above on a timeline, which we decline to make rather than make loosely.
The first item in the left column is the one buyers most often miss and it changes the calculation more than people expect: your data can be entirely French. What is English is the frame around it.
What is not built for Senegal 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 Senegal. 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 DGID declarations, 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.
DGID declarations and e-invoicing
Declaration output in the format the administration expects and electronic invoicing against any prescribed interface, with retries, a failure queue and a reconciliation report.
Wave, Orange Money and bank feeds
Mobile money settlement files and bank statement feeds pulled into the Payments Register, so collections match invoices without anyone re-keying a statement.
Payroll and statutory returns
IR, IPRES and CSS schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt in a spreadsheet 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 integratedWhere to go next
Country-level buying advice, where this question is usually decisive, is in the Senegal buyer's guide and the Côte d'Ivoire buyer's guide. The other half of what makes this market distinctive — the statutory accounting boundary — is in OHADA, SYSCOHADA and your operations system. For a comparable analysis in a market with two working languages and a different script, see Arabic, French and the localization nobody tests.
Our take
Answer the two questions separately and in the right order. First: can you staff the roles at the point of capture — the counter, the depot, the warehouse — with people who work in English, continuously, through turnover? If not, stop; nothing downstream matters, because the data will not be reliable. Second: what leaves the building, and to whom? If your counterparties are local, either issue those documents from somewhere else and accept the reconciliation point, or buy locally for the whole system. Organizations with international counterparties, a stable and bilingual operational team, or a group standard to meet can make this work well. Domestic businesses working entirely in French usually should not, and we will tell you so in the first call rather than the third month.
Ask us the uncomfortable version of the question
Describe your least-trained site and your most local customer. We will give you a straight answer, including when that answer is to buy from someone else.
Get a straight answerFrequently asked questions
Is a French version of the interface planned?
We are not making a commitment on a timeline, and we would rather say that than offer a soft promise you might rely on. There are no translation files in the product today and no setting waiting to be enabled, which means French is not a configuration away — it would be substantial work. If a French interface is essential to you, treat us as not having one and evaluate accordingly, rather than buying on the expectation of a change.
Can we at least enter our data in French?
Yes, entirely, and this matters more than most buyers expect. Item names and descriptions, customer and supplier names, location names, project and cost-centre names, notes, justifications and attached documents are all free text that we do not alter. A daily user in the warehouse is mostly reading item names and location names, which can be wholly in French. What stays English is the frame — the menus, field labels and buttons.
Will invoices and delivery notes print in French?
No. All printed output is in English, including invoices, purchase orders, delivery notes, receipts and payslips. For a business whose customers and suppliers are local this is a genuine commercial consideration. A common arrangement is to issue customer-facing documents from a local accounting package or through your expert-comptable while the operations system runs everything internal — that works, and the honest cost is a reconciliation point between two systems that both know about the same sale.
Could we use browser translation?
We advise against it. Automatic translation breaks page layouts, renders domain terms inconsistently so the same button reads differently on different days, and translates your data as well as the labels — which means a user may be reading a machine-translated version of a supplier name or an item description. That is worse than an English label, because it looks like information rather than like a gap. A short bilingual reference card at each workstation is cruder and considerably safer.
Can implementation and training be in French?
This is separable from the product language and worth insisting on regardless of which vendor you choose. Training delivered in your team's language on an English-language system is entirely workable, and the quality of the trainer matters more than the interface. Raise it during selection rather than after signing, and get it written into the implementation scope — a vendor unwilling to train in your language is asking you to absorb the whole cost of the mismatch.
How do we decide whether this is a dealbreaker for us?
Take a demo to your least-trained, highest-turnover site rather than to head office, and ask someone who works there to complete a real task without help. If they cannot, the answer is no regardless of how well head office manages, because that site is where your data originates and unreliable capture undermines everything above it. Then ask two or three actual customers how they would feel receiving an English invoice. Those two tests, together, settle it more reliably than any internal discussion.
When should we simply buy from a local vendor instead?
When your business is domestic, your customers and suppliers are local, and your staff work in French. In that situation a capable Senegalese, Ivorian or regional vendor will serve you better than we will, and no operational depth on our side compensates for a system your team cannot comfortably use and documents your customers find foreign. We reach this conclusion on first calls regularly and prefer to reach it quickly. The organizations we fit are those with international counterparties, a stable bilingual operational team, or a group operations standard to meet.
