ERP Business Analyst in Switzerland

What makes Swiss ERP requirements different

Requirements for a Swiss company rarely fit a template written for a single-country business. A typical requirement set has to deal with several currencies in daily use, a VAT system that sits outside the EU framework, cross-border goods that pass through customs, bank formats specific to Swiss payments and documents produced in more than one national language. Add a parent company or foreign subsidiaries, and group reporting rules join the list.

When these points are left implicit, they surface late. A vendor demo shows a clean invoice in one currency and one language, the shortlist is agreed, and the gaps appear during configuration when changes cost far more. My aim as a business analyst is to bring them forward, into the requirements document, where they can shape the choice.

I start with business analysis sessions for each area: sales and customer service, purchasing and logistics, treasury, accounting and reporting. For each one I collect real examples, such as an export invoice, a supplier invoice with a QR-bill attached, a bank statement and the reports management reads every month. Those examples become the test data later, which keeps vendor demonstrations honest. The wider Swiss context for this work is set out on the ERP consultant in Switzerland page.

Swiss VAT, QR-bills and bank files as requirement lines

Swiss VAT is the finance chapter where precise wording matters most. With your fiduciary or tax advisor I list the treatments the company actually uses, for example domestic supplies, exports, imports of goods, services bought from abroad and any items handled outside VAT, and the reporting they expect for each period. If the company uses a simplified method agreed with the tax authority, the requirement says so, because not every platform supports every method in the same way. Choosing the treatment stays with the advisor, while I make sure it is explicit and testable.

Payments get their own chapter. Swiss invoices commonly carry a QR-bill, so I write requirements for producing it on outgoing invoices in the right layout and for capturing incoming QR-bills into supplier invoices without retyping. Bank connections follow: which banks you use, which payment and statement files they exchange, and how statements should match open items.

Each of these lines is later tested with your own data during demonstrations. Platform-specific findings are discussed in more depth on the Odoo in Switzerland, Zoho in Switzerland and ERPNext in Switzerland pages, and the scoring method is on my gap analysis page.

Mapping trade, customs and intercompany flows

Many Swiss companies earn their margin across borders, so the process maps have to show what happens at each crossing. For a trading company that might be a purchase contract in dollars, a sale in euros, freight booked through a forwarder and a bank financing the shipment. For an exporter of components or instruments it might be production in Switzerland, delivery to an EU distributor and service visits billed months later. Each flow needs its own map, with the documents and data that travel with the goods.

Customs is a frequent blind spot. I record what your forwarder or customs agent needs from the ERP, such as tariff numbers, origin details, weights and values, and where that information is maintained today. I also note which import costs should be added to stock value and how that is calculated, so the requirement covers both logistics and finance.

Intercompany flows complete the picture. Where a Swiss headquarters recharges services, sells to sister companies or holds cash on behalf of the group, I map who invoices whom, in which currency and with what timing, and write requirements for automatic intercompany documents and reconciliation. These maps are built using the method on my process mapping page.

Stakeholders across regions, group functions and staff

Swiss requirement work often involves more voices than the size of the company suggests. A firm based in Zurich may run its finance shared service in Lausanne and a sales team in Lugano, each with its own habits and language. A Swiss subsidiary answers to group finance and group IT abroad. A family-owned exporter may need the owners themselves to approve priorities. I plan the workshops so each group is heard, and I record in the document who requested each requirement.

Staff-related topics need care as well. If the system will record working time on jobs, track user activity or store personal data about employees and customers, I list those points so management and any employee representatives can discuss them openly. Data protection follows the same pattern: I describe what personal data the ERP and CRM will hold and who can access it, and your legal advisor assesses the result against Swiss data protection requirements and, where you serve EU customers, GDPR.

Payroll usually remains with a Swiss payroll provider or the fiduciary. The specification defines what the ERP sends and receives, typically cost centers and summarized postings, so that boundary is clear before an implementer quotes.

English documents with multilingual review

Deliverables are written in English: requirements, process maps, the fit-gap matrix and every test scenario. That usually fits Swiss companies where management, group finance and international partners already work in English. The national languages still matter, because invoices, delivery notes, reminders and customer letters often have to go out in German, French or Italian.

I handle that by treating language as a requirement rather than a translation task. The output inventory lists every external document with the languages it needs, the legal and payment information it must carry and who approves its wording. Your multilingual staff then review sample layouts and terms in each language, and they, or a local partner you appoint, prepare the translated templates and user guides. That keeps the terminology in the hands of people who use it every day.

Workshops are held online in the Swiss morning and early afternoon, inside my own working day in India, and every session ends with written notes. Sign-off is recorded per chapter: finance, treasury, operations, sales and IT. After that, changes go through a simple request log. For document structure, see my BRD consulting page, or return to the Switzerland hub for an overview of my work in this market.