English and Greek, one workflow: building Clivanta for Cyprus firms

A manager in a Nicosia firm drafts a request list in English, because that is how the team works, how the file is reviewed, and how the workpapers read. Then she picks up the phone to the client’s bookkeeper, who is far more comfortable in Greek, and translates the same three asks on the spot. She writes the email in Greek too, to be safe. Two versions of the same request now exist, and only one of them is in the system.

This is the quiet tax of working in a bilingual market. The firm operates in one language; a good share of clients live in another; and the ask has to be clear to both sides without anyone maintaining two copies of it. Most collection tools are built for a single language, so firms end up doing the translation by hand, in the margins, where it leaves no record.

The firm and the client don’t share a language — they share a Request Item

The unit that both sides act on is the Request Item: one specific ask, with its own status, instructions, and files. The trick is that the firm and the client can meet on that same item from opposite ends of a language boundary.

Your team builds and reviews in English. A Client User opens the Portal and sees the interface in the language their browser prefers. Clivanta detects browser language and renders the client space and the emails in English or Greek accordingly, so a Greek-speaking bookkeeper is not made to parse an English dashboard before they can work out what you need from them. The status of the item, the conversation on it, the versioned files, the immutable activity log — those are the same underlying record whichever language it is viewed in. There is one workflow and one record. Only the surface changes.

That distinction matters. A firm cannot run two parallel processes, one English and one Greek, and still keep a defensible trail. The moment “what we asked for and what we received” lives partly in a translated email and partly in the system, you are back to reconciling by hand. Keeping the item as the shared object, and translating only the presentation, means the record stays whole.

Where the two languages actually meet

Bilingual support is not a checkbox. It shows up at the specific points where the firm and the client touch the same work:

• The client space. A Client User sees Engagements, what needs their action, and a plain “what’s still missing” summary in their language, with browser-language detection choosing the default.
• Notifications. The request email, the reminder that names the outstanding items, the escalation that CCs the Client Owner — these reach the client in the language they read, not the language your team drafts in.
• The upload flow. Per-item and bulk upload, drag-and-drop, on a phone at the client’s kitchen table on a Sunday evening. If the buttons and prompts are in a language the client hesitates over, they will close the tab and reply to your email instead. The point of the Portal is that they do not.

What deliberately does not change language is the firm’s own working record. Your worklist, your internal comment thread, your Evidence index, the workpaper exports — those stay in the language your team and your reviewers use. The client sees a Greek prompt to upload a bank statement; you see the same item in your English worklist, with its status read from stored, audited state. Neither side is asked to work in a language that slows them down.

Why local fit beats a bigger generic tool

There is always a larger, better-funded tool from somewhere else that a Cyprus firm could adopt. On paper it does more. In practice, a document collection tool lives or dies on whether the client’s client — the occasional user, uploading twice a year, under a deadline — can act without friction. For a Greek-speaking client, an English-only portal is friction of exactly the kind that sends people back to email.

Local fit is not only language, though language is the visible part of it. It is knowing that the work is statutory audit, VAT, VIES, payroll, and AML on a Cyprus calendar, that the same asks recur every quarter, that the firm bills in euros and reviews in English while the client base is mixed. A tool built with that market in view can ship the seeded templates that match the work and the bilingual surface that matches the client base, rather than treating both as configuration the firm has to bolt on.

None of this requires the firm to compromise. You are not choosing between a process that suits your team and one that suits your clients. The Request Item lets both hold at once: the firm keeps its English record and its structured evidence, the client gets a Greek portal that tells them plainly what to send. The bilingual part is invisible precisely because it is doing its job.

One record, two front doors

Think of it as one workflow with two front doors. Behind either door is the same set of Request Items, the same status lifecycle from requested to submitted to accepted, the same versioned files retained as previous attempts, the same audited history. The door a client walks through is chosen for them, by their browser, without a settings page or a support ticket. The firm never sees a second system.

This is the difference between supporting a language and being built for a market. Supporting a language is a toggle. Being built for Cyprus means the default is already right, the templates already match the filings, and the client is already reading your request in the language they think in — while your team, upstream, has done nothing different at all. You can read more about the people and thinking behind Clivanta if that origin matters to you.

The client should never notice the language was ever a question. That is the whole point.