System Integration Consultant, Sweden

What usually sits around a Swedish ERP

Before anyone discusses connectors, I build an inventory of the systems that already exchange data with your ledger, including the ones nobody thinks of as integrations. In Swedish companies the list tends to include:

• Banks: outgoing supplier payment files, incoming account statements and receipt files carrying OCR references.
• A Peppol service: either built into the ERP or bought from a separate access point provider, for invoices to public bodies and to larger companies that require them.
• A supplier invoice inbox: scanning or interpretation services that turn PDFs and e-invoices into draft vendor bills for approval.
• Payroll: a Swedish payroll service that posts salary journals and sometimes receives hours or absence from a time system.
• Sales channels: a Shopify or WooCommerce store, marketplaces abroad and a CRM sending orders and customers.
• Warehousing: a third-party logistics provider sending shipment confirmations and stock levels.
• The accounting firm: often receiving an SIE file rather than a live connection.

For each item I record what moves, how often, by which method and who notices when it stops. The result is usually a single data flow diagram that finance, IT and management can read. It shows quick wins, such as a bank connection that was bought but never switched on, and risks, such as payroll journals typed by hand from a PDF.

Bank files and OCR receipts, specified properly

Payment integration in Sweden looks simple on a slide and turns detailed in practice. Supplier payments leave the ERP as a file or an API call, are approved somewhere, and reach the bank. Receipts come back as statement data, ideally carrying the OCR reference printed on your invoice, so the ERP can match them without a person reading each line.

The specification I write answers questions that are easy to skip:

1. Which file format and channel each bank supports for your account type, confirmed with the bank rather than assumed.
2. Whether payments are approved in the ERP, in the bank's portal or in both, and who holds each approval right.
3. How the OCR reference is generated, which check digit method is used and where it appears on the invoice.
4. What the ERP does with a receipt whose reference is missing, wrong or covers several invoices.
5. How rejection and status messages from the bank reach the person who can correct the payment.

Currency accounts add another layer. If you hold euro or dollar accounts, the specification states how foreign receipts are matched and where exchange differences post, which your accountant confirms. Bank requirements change from time to time, so I record the version agreed and the contact responsible on both sides. The detailed bank-side checks often sit with the implementation partner, but they test against this document. For the wider ERP view, see my ERP integration service.

Peppol sending, receiving and the invoice inbox

Sending invoices over Peppol involves more than switching on a feature. An access point has to be chosen or confirmed, your company has to be registered so buyers can find you, and every invoice must carry the data the receiving organization validates. Swedish public buyers in particular tend to reject documents without the buyer reference they asked for. Your advisor or the buyer's own instructions confirm what is currently required.

For outgoing invoices I define:

• Which customer master fields hold the electronic address and mandatory references, and where they are captured, often in the CRM before the deal closes.
• Whether sending runs from the ERP's own Peppol module or through an external provider, and how status messages return.
• Who receives a rejection, how it is corrected and how a corrected invoice or credit note is sent.

Incoming invoices are the other half. Suppliers send Peppol documents, PDFs by email and occasionally paper. I design one intake route where possible, so every bill lands in the same approval flow, matched to a purchase order where one exists and posted only after attestation. Duplicate detection belongs here too, since the same invoice can arrive both electronically and by email. The CRM consultant page for Sweden describes how buyer references get captured at the sales end.

Native apps, middleware or custom code

Swedish ERP buyers have a wide choice of ways to connect systems, and the right answer often mixes several. I compare them interface by interface rather than picking one approach for everything.

For apps, I check who maintains them, how quickly they followed past format changes and what happens to your data if the app is withdrawn. For middleware such as Zoho Flow, Make, n8n or Power Automate, I check licensing, logging and who in your company can read a failed run. For custom code, I ask who owns the source, where it is hosted and who will update it.

The build sits with your developers, your implementation partner or a specialist firm. My role is to make sure what they build matches the agreed design, and that the trade-offs were made deliberately. The system integration page sets out the general method.

Testing, monitoring and ownership after go-live

An integration that passes a happy-path test can still fail on the first busy Monday. I write test scenarios around the cases that break Swedish finance flows:

• A customer pays two invoices with one OCR reference, or pays with none.
• A municipality rejects a Peppol invoice because a reference is missing.
• A supplier payment file is rejected by the bank after approval.
• A webshop order is cancelled after the 3PL has already picked it.
• A payroll journal arrives with a cost center that no longer exists.

Before sign-off, your finance team ties out selected transactions in each connected system, so acceptance rests on matching totals rather than on screenshots.

Monitoring is designed at the same time. Each interface gets a log, a retry rule for temporary failures and an alert to a named person, not a shared mailbox. A short runbook explains common errors in plain language. An ownership matrix states who answers for each interface: finance for unmatched receipts, IT or the partner for credentials and certificates, operations for webshop and warehouse flows.

Ownership also covers change. When a bank updates its file requirements or the ERP vendor releases a new version, someone has to retest the affected interfaces. That responsibility is written into the support agreement before go-live. The Sweden page links to the other remote services I offer Swedish companies.