A Québec subsidiary reporting into an anglophone parent has a problem that does not appear on any risk register. The month end runs in French, the group pack is read in English, and somewhere between the two the numbers have to survive a translation performed under deadline by whoever is available.
It sounds like a minor operational irritation. It produces real errors, and it costs more than most groups realise.
Where the language question actually bites
Not in the obvious places. Nobody mistranslates “revenue”.
It bites in the chart of accounts, where an account named in one language gets mapped to a group code named in another by someone who had to guess. It bites in accruals and provisions, where the description is the only record of what the balance is for, and a vague description in a second language becomes an unexplained balance within a year. It bites in the audit, where a supporting document in French is handed to a reviewer who does not read French, and the evidence effectively ceases to be evidence.
And it bites in the handover. When the person who maintained the bilingual mapping in their head leaves, the mapping leaves with them.
The expensive answer
The instinct is to run two sets of records, one for local purposes and one for the group. It solves the immediate problem and creates a worse one.
Two ledgers diverge. Not immediately, and not dramatically, but a journal posted in one and not the other, a correction applied on one side, a cut-off applied differently, and within a few periods you have two defensible answers to the same question and no way to tell which is right. Then you are not running a finance function, you are running a reconciliation between two finance functions.
It also doubles the month end and makes the audit materially more expensive, because the auditor has to understand both and reconcile them.
The cheaper answer
One ledger, described twice.
The chart of accounts is where this is won. Each account code carries a description in both languages, maintained together, so the same trial balance renders in French or in English from a single source. Nothing is translated after the fact because nothing needs to be: the reporting layer picks the language and the numbers are identical by construction.
Three things follow from getting that right.
Narrative gets written once, in the language of the person who knows the answer, and translated deliberately rather than hurriedly. A provision explained properly in French by the controller who raised it is worth more than a thin explanation in English written by someone reconstructing it.
Supporting documents get a one-line summary in the second language when they are filed, not when they are requested. A contract stays in the language it was signed in, with a short note saying what it is and where the key terms sit. That single habit removes most of the friction from a bilingual audit.
Statutory and management reporting stop being confused with each other. The statutory filing has its own language requirements and its own format. The management pack has one job, which is to be understood by the people making decisions. They come from the same ledger and they do not have to look the same.
What it costs
Setting the chart of accounts up properly is a few days of work, once. Maintaining it is close to free, because you are adding a second description at the moment you create an account rather than retrofitting hundreds of them later.
The retrofit is the expensive version, which is the argument for doing it before the group gets larger rather than after. If you are a Québec business about to be acquired by an international parent, or an international group about to buy one, this is cheap work to do in the first month and tedious work to do in the third year.
The thing that is not a language problem
Worth saying plainly, because it comes up often. When a Québec team and a group finance function arrive at different numbers, the cause is usually not the language. It is different accounting policies, a different cut-off, or a different exchange rate, and the language barrier is just making a real disagreement harder to locate.
Reconcile the policies first. If the numbers still differ, you have an accounting problem and you were always going to have it. Bilingual reporting done properly does not fix that. What it does is stop you spending two weeks looking for a translation error that was never there.