ERP Requirements Consultant, Sweden

How a Swedish specification is organized

A specification that bidders can price and testers can use needs a predictable shape. I organize it in layers, so a reader can find any line quickly and nothing important hides inside a paragraph.

• Context: entities, volumes, users, sites and the systems that stay in place.
• Functional sections by process area: quote to cash, purchase to pay with the attest chain, inventory and logistics, projects or service, and record to report.
• Swedish statutory annex: accounting exchange, VAT, e-invoicing, payment references, retention and language of documents.
• Non-functional section: hosting, security, audit trail, performance and availability.
• Integration and migration sections: each interface and each data object, with ownership.
• Glossary: Swedish terms such as attest or verifikation explained once, so an international bidder reads them the same way as a local one.

Each line gets an ID, an owner, a priority, a source and a short rationale. Requirement discovery itself, the workshops and process maps, is covered on my ERP business analyst page for Sweden. This page is about turning that material into a document that holds up when money and contracts depend on it. The general method sits under ERP requirements gathering.

Turning Swedish obligations into testable statements

The difference between a weak and a strong specification is usually visible in the statutory lines. A weak line names a topic. A strong one describes an observable result that a bidder can show and a tester can tick off. Some examples of the phrasing I aim for:

• The system produces an SIE file of the type our accounting firm uses, which opens in its software and agrees with the trial balance for the same period.
• Outgoing invoices to public buyers leave as Peppol documents carrying the buyer reference, and a rejected document returns to a named user with the reason visible.
• Incoming Peppol invoices arrive in the attest queue with the original document attached.
• Every customer invoice prints an OCR reference that the system can match automatically from the bank file.
• VAT report boxes are filled from tax codes in a mapping that our tax advisor has reviewed and approved.
• Vouchers, attachments and change history remain retrievable for the retention period our auditor confirms.

I do not decide what Swedish law requires. Your tax advisor and auditor confirm the obligations, and the specification records who confirmed each one. My contribution is precise wording, so that a later dispute is about whether the system passed a test, not about what a vague sentence meant.

Non-functional requirements Swedish buyers tend to leave out

Functional lists get attention because process owners write them. Non-functional needs often have no owner, so they appear as a single line about security. In a Swedish context, I give this section its own structure.

• Data location: where the production database, backups and support access sit, whether an EU or EEA region can be chosen and how subprocessor changes are announced. The answers go to whoever owns GDPR in your company.
• Access control: roles aligned to the attest chain, segregation between creating suppliers and approving payments, and how temporary deputies are handled.
• Audit trail: who changed a posted entry, a bank detail or a price, and whether that history can be exported for the auditor.
• Performance: acceptable behavior during month-end runs and large payment proposals, described as expectations to discuss rather than invented figures.
• Availability for remote sites: what a warehouse, workshop or northern site with weak coverage must still do when the connection drops.
• Exit: how a complete export of data and attachments is delivered if you leave.

These lines rarely decide a selection on their own, but they are hard to add once the contract is signed.

Interfaces, migration lines and traceability

Swedish companies rarely replace everything at once. The payroll system, the bank, a webshop, a time reporting tool and the accounting firm often stay where they are. For each interface the specification states direction, frequency, trigger, the data carried, error handling and who owns it. The payroll line, for instance, says that the payroll provider delivers a journal the ERP imports by cost center, rather than assuming the ERP runs Swedish payroll.

Migration requirements follow the same pattern. They state which open items, balances, history and documents move from Fortnox, Visma or an older system, what is archived instead and how each object is reconciled. An SIE file from the old system can support that reconciliation, but the specification says so explicitly.

Priority is agreed with process owners using must, should, could and will-not labels. A must line is one where failure would stop you signing. Each line then carries two more references: the demo scenario that will show it during selection and the acceptance test that will prove it before go-live. That chain lets anyone follow a Swedish obligation from the specification through the fit-gap analysis to user acceptance testing without guessing.

Using the specification with bidders, and gaps to watch

Once baselined, the specification becomes the requirement annex in the bidder package. Each bidder answers line by line using the same response codes, and the scripted demos on my ERP selection page for Sweden draw directly on it. If your organization follows public procurement rules, your procurement advisor decides the formal tender format, and the specification fits inside it. Before signing, the agreed version is referenced in the statement of work, so acceptance is measured against it. The ERP RFP consulting page explains the wider tender pack.

Version control matters more than many teams expect. I keep a numbered version history, a change log stating why each line changed and a record of who approved each version. Late changes go through the same route, so the contract never points at an outdated draft.

Gaps that create risk in Swedish specifications include:

• Peppol sending specified, but receiving and attest of incoming documents forgotten.
• SIE described only as an export that exists, with no check by the accounting firm.
• No line on how attest rights move when approvers are on long leave.
• Retention of old vouchers left out because the old system is assumed to stay available.
• Swedish invoice and reminder layouts treated as cosmetic.

The Sweden overview lists the other remote services I offer there.