Treat language, business entity and user permissions as separate requirements when commissioning multilingual software. A user choosing French should not automatically receive a different price list, approval authority or data-access boundary. For organisations operating in Belgium, Luxembourg or Switzerland, keeping these decisions distinct makes both procurement and testing more precise.
These markets are useful examples of why country-level assumptions are insufficient. Your actual employees, customers and partners determine which languages and workflows need support. This guide does not prescribe a legal language policy or treat the three countries as one jurisdiction. It explains how a buyer can define a maintainable application for the people and entities it actually serves.
Build a requirements matrix from real roles
Start with a list of roles and the tasks each performs. Identify the business entity, data boundary, working language and document requirements for each task. A person may work in one language while approving a transaction for a different entity. A customer may need an invoice in a language different from the interface preference.
Ask process owners to review these combinations before developers design account settings. A single “country” field often becomes overloaded with unrelated rules. Separating the decisions early helps the team explain why a particular user sees particular data and documents.
- ▸Which entity owns the customer relationship and transaction?
- ▸Which role can view, change or approve the record?
- ▸Which interface language does the user prefer?
- ▸Which language and template apply to the resulting document?
- ▸Which person approves changes to each rule?
These questions should be answered with concrete examples, including users who do not fit the default combination.
Decide what changes with the language selector
A language selector should change agreed presentation behavior while preserving the underlying transaction. Define what happens to unfinished forms, validation messages, notifications and links when a user changes language. A saved record should retain its stable identity.
The W3C internationalization guidance addresses language declaration and international form handling. Apply those fundamentals, then add the business decisions that standards cannot make for you. For example, decide whether a quotation records the document language at issue time or follows the recipient's latest preference when downloaded again.
Ask the supplier to demonstrate longer labels, local characters and realistic names. Agree how search handles identifiers and translated descriptions. A customer reference should remain findable even when its visible label has changed, while translated product descriptions may require a separate search design.
Example: a shared purchasing workflow
Imagine a group using a shared purchasing application across teams in Belgium, Luxembourg and Switzerland. This is an illustrative scenario. A requester submits a purchase, a manager approves it and a finance team exports the result to the appropriate accounting system.
The requester prefers French, the manager uses German and the finance reviewer uses English. Their language choices should not change the approval limit or move the purchase to a different entity. The approval record must refer to the same transaction throughout.
The acceptance test should include an entity change before approval, a corrected supplier address and a reopened request. The buyer must decide which changes invalidate the previous approval. Without that decision, a technically functioning workflow may preserve an approval that no longer matches the transaction being purchased.
Version documents and decisions together
Important documents need an explicit lifecycle. Identify who owns each template, who approves translations and which version applies when a document is issued. Consider whether users need the original issued version, a regenerated copy or both.
Do not allow a template update to silently rewrite the meaning of a past approval. Record the business decision about document history and give the supplier examples to test. Where record-retention, contractual or language obligations apply, obtain the specific requirements from the responsible advisers rather than asking developers to infer them.
Editorial ownership is also part of maintenance. A newly introduced status needs approved labels, explanations and support instructions in the supported languages. Make that work visible in the release plan instead of leaving translation as a final informal task.
Keep access checks independent of presentation
Language is not an access-control boundary. A user should not obtain another entity's records by changing a locale, a URL parameter or an account preference. Ask the supplier to test access through direct links and integration endpoints as well as through the intended screens.
Include the export path in those checks. An interface that hides records correctly can still generate an overly broad report if export permissions are implemented separately. Request evidence for the roles and data boundaries that matter to your organisation.
Our API security article provides background for conversations with the engineering team. Use it to prepare questions, while keeping acceptance tied to your specific application and roles.
Price a shared application honestly
A shared codebase can reduce duplicated implementation, but it still requires configuration, language review and testing for meaningful combinations. Ask the proposal to distinguish common behavior from entity-specific rules and show how exceptions are maintained.
Too many exceptions may indicate that the business has not yet agreed a shared process. Explore that during discovery. Sometimes a common core with explicit variations is sensible; sometimes forcing different workflows into one screen creates confusion. The buyer should understand the tradeoff before accepting a universal-platform promise.
For remote development, name the people who can answer language and business-rule questions. Agree the language of engineering documentation separately from user-facing content. A supplier should state its actual delivery capabilities and where qualified reviewers are needed.
Request a proposal using three difficult examples
Send one ordinary transaction, one transaction crossing a language or entity boundary, and one correction after approval. Include expected documents and the roles involved. This brief gives shortlisted teams something concrete to explain and estimate.
Use our European software vendor scorecard and requirements-document guide to compare responses. TuniCyberLabs offers custom business software and integration engineering. Request a multilingual workflow scope with your examples, languages and systems, so that the proposal can separate shared functionality from the variations your organisation genuinely needs.