Contact Info
Switzerland
What goes into a Swiss company's ERP requirements specification?
An ERP requirements specification for a Swiss company is the signed document integrators quote against and testers check. It lists functional requirements by process area, Swiss statutory needs written as testable statements, such as QR-bill output, VAT reporting confirmed by the fiduciary and record retention, plus hosting, access, interface and migration requirements, each ranked by owners and linked forward to demo steps and acceptance tests. I draft and keep it current remotely.
Last reviewed by Vikas Saroj
A Swiss ERP project is only as clear as the document behind it. When a specification says "supports Swiss VAT" or "handles QR-bills", every vendor answers yes and the real differences appear during the build. As an ERP requirements consultant, I write the specification as numbered, testable statements, so each answer can be checked in a demo, priced in an offer and accepted in a test.
The document covers the whole system: process areas from quote to close, Swiss statutory outputs confirmed by your fiduciary, hosting and access rules, interfaces to banks and payroll, and the data you bring across. Each line carries a priority, an owner and a reference that follows it into the demo script, the contract and user acceptance testing.
I work remotely and independently and accept nothing from vendors or integrators. The engagement itself runs in English; any wording that must appear in German, French or Italian is written or checked by your own team.
What I Do
The specification is built to be read by people outside your company, so every line has to mean the same thing to an integrator, your fiduciary and your test team.
A fixed chapter layout: scope and entities, process-area requirements, Swiss statutory lines, non-functional needs, interfaces, migration and reporting. Every line gets a reference, an owner and the workshop it came from, so readers find things quickly.
Statements such as "the invoice prints a QR-bill payment part with a structured reference" instead of "Swiss compliant". Your fiduciary confirms the VAT and retention content; I make each line precise enough to demonstrate and test.
Questions on hosting region and backup location, role-based access with dual approval of payments, an audit trail on master data, response times for sites in other cantons or abroad, and support hours that match your working day.
Bank payment and statement files, eBill where you use it, payroll postings, customs data, e-commerce and CRM links, plus the history, open items and master data the new system must receive, each with a named data owner.
Every owner ranks their lines as must, should, could or later, and each must has to carry a stated reason. The result keeps integrator offers comparable and gives the steering group a fair basis for later scope decisions.
A change log, a frozen version for the request for proposal and another for the contract, signed by each process owner and the sponsor. After that, edits go through a change request rather than an email thread.
How I Work
Collect needs from every owner
Process-area workshops with owners
Fiduciary review of statutory lines
IT input on hosting and access
Interface and data inventory
Turn notes into testable statements
Numbered, testable requirement lines
Priority agreed by each owner
Demo script references added
Open questions logged with owners
Freeze a version vendors can quote
Sign-off by owners and sponsor
RFP annex version issued
Contract version with acceptance links
Change log for later edits
Think of the Swiss specification as a contract exhibit in waiting. It records what your company needs in a form that an outside integrator can price and an internal tester can prove. For a Swiss company I organize it in chapters that every reader learns once:
Each line follows the same pattern: a reference, a single statement, the reason it matters, the priority, the owner and a short note on how acceptance will be shown. A line that cannot be given an owner or an acceptance note is usually not a requirement yet; it goes to the open questions list until someone can answer it.
Discovery work feeds the document, and that side is described on my ERP business analyst page for Switzerland. This page is about the specification itself and what happens to it afterwards.
Swiss obligations are where vague wording causes the most expensive surprises. The content of each line comes from your fiduciary or tax advisor, who confirms how VAT, retention and reporting apply to you. My job is to turn that guidance into statements a vendor cannot answer with a simple yes.
| Vague wording | Testable wording |
|---|---|
| Supports Swiss VAT | Calculates VAT per tax code agreed with the fiduciary, including import VAT taken from customs documents, and produces period totals in the layout the fiduciary uses for the return |
| Handles QR-bills | Prints a QR-bill payment part with a structured reference on outgoing invoices, reads incoming supplier QR-bills and matches receipts by reference |
| Keeps records | Stores postings with their attached vouchers unchanged and searchable for as long as Swiss bookkeeping rules require, as your advisor confirms |
| Multilingual | Selects the document language from the customer record and prints invoices, reminders and delivery notes in German, French or Italian |
| Payroll integration | Imports the payroll journal by entity and cost center from the external payroll package, with a reconciliation report |
Where a requirement depends on a method agreed with the tax authority, such as a simplified VAT method, the line names it, because platforms do not all support the same methods in the same way. Salary reporting to authorities usually stays inside the Swiss payroll package, so the specification asks only for the posting interface and leaves the reporting standard to your payroll provider to confirm.
Many specifications stop at features. Swiss boards and auditors then ask questions the document never covered, and the answers sit in a sales slide rather than the contract. I write these needs as requirements in their own chapter:
Written this way, these lines can be scored during selection and tied to service levels in the agreement, instead of being discussed for the first time after go-live.
A specification without priorities invites inflated offers. I run short sessions where each owner classes their lines as must, should, could or not in this phase, and a must has to be backed by a reason such as a legal obligation, a customer contract or a control your auditor relies on. The sponsor settles disputes between departments, so the final list reflects the business rather than the loudest voice.
Traceability then links each line forward:
In a vendor process, the frozen specification becomes the requirement annex of the request for proposal. Integrators answer line by line in a fixed template, which makes their offers comparable; the method is described under ERP RFP consulting, and the shortlist and demo stage under ERP selection for Switzerland. At contract stage, the frozen Swiss version becomes an annex to the statement of work, and acceptance is tied to the related test cases. The testing and UAT scripts are then drafted from the same references, so nothing silently drops out between the offer and go-live.
Certain omissions are a recurring risk in Swiss requirement documents. Each one tends to stay hidden until configuration or testing:
Keeping the document alive matters as much as writing it. I hold a version history with a change log, freeze a baseline before the request for proposal, freeze another for the contract, and route later edits through a change request that names the requester, the reason and the impact. Sign-off is collected from each process owner and then the sponsor, with comments resolved in writing.
All of this runs remotely through workshops on video calls and shared documents, with a visit by arrangement if the steering group wants one. The resulting specification, annexes and traceability matrix belong to you. For the wider picture of my work with Swiss companies, see the Switzerland overview or my ERP requirements gathering service.
Tell me about your business and current systems. I’ll suggest the most sensible first step.
Book a Consultation
Not sure which ERP you need?
Share your business requirements with me and I will help you understand the right process, architecture and platform before implementation.
FAQ
Business analysis is the discovery work: interviews, process maps and understanding why things happen. The specification is the formal output that leaves your company, gets quoted by integrators and is attached to the contract. I can do both, but if your team has already mapped its processes, I can start from that material and focus on writing, prioritizing and baselining the document.
Your fiduciary or tax advisor. They decide how VAT applies to your transactions, which method you use and how long records must be kept. I take their guidance and write it as requirement lines with acceptance notes, then ask them to review those lines before the version is frozen. Legal points on data protection go to your legal advisor in the same way.
Often that is a sensible starting point, especially if the group wants a common ERP template. I review the template, mark which lines apply as written, which need a Swiss variant and which are missing, such as QR-bills, franc and euro handling or local document languages. The Swiss additions then sit in a clearly labelled local chapter.
No. The requirements describe what the business needs, not how a particular product delivers it. Naming a product early tilts the vendor process and weakens your negotiating position. If you already have a preferred system, the same document is still useful, because it becomes the fit-gap baseline and the acceptance reference for that one integrator.
It becomes the reference for design reviews, change requests and testing. The integrator's design is checked against it, every change request refers to the affected lines, and the user acceptance test cases trace back to it. Keeping it under version control through the project is what makes it useful for scope disputes and for the final acceptance decision.
Every business is different. Share where you are today and what you want to fix, and I’ll tell you honestly whether and how I can help.
Book a Consultation
Insights
Book a Consultation
Book a consultation to talk through your processes, systems and goals. I’ll reply with practical next steps - no obligation.
