Automate Supplier Invoice Data Entry into Fortnox with OCR

Fortnox's native OCR: Fakturatolkning explained

Fortnox is the leading accounting software in Sweden, and it does not leave supplier invoices to manual keying. Its native OCR is called Fakturatolkning, which translates as "invoice interpretation". It is a paid add-on that reads incoming supplier invoices, extracts the key fields — supplier, invoice number, dates, amounts, VAT and OCR payment reference — and presents them for review inside Fortnox.

For standard Swedish supplier invoices, Fakturatolkning is genuinely good. It is trained on the documents Swedish businesses actually receive, it understands local formats such as the OCR payment reference line, and it lives inside the same system where the invoice will be booked and paid. If your invoice flow is mostly conventional PDFs from Swedish suppliers, the native option is often the simplest and most reliable starting point, and we would not steer you away from it lightly.

The trade-off is that interpretation is typically charged per invoice, and Fakturatolkning is designed around the kinds of documents it expects. Receipts, photographed slips, or non-standard layouts can fall outside its comfort zone. That is where a custom flow — the sort of pipeline we discuss in OCR for accounting — starts to earn its place. Note that features and pricing change, so always confirm the current add-on terms with Fortnox before you commit.

How OCR data reaches Fortnox: the SupplierInvoices API

Whether the data comes from Fakturatolkning or from your own OCR pipeline, it ultimately has to land in Fortnox as a record. Fortnox exposes a modern REST API secured with OAuth2, and among its resources is SupplierInvoices, reached with the supplierinvoice scope. This is the endpoint you use to create and read supplier invoices programmatically.

A custom flow that uses this API generally follows a clear shape:

1. Capture the document — from an inbox, a shared folder, or an upload.
2. Run OCR and structure the fields you need: supplier, invoice number, dates, net and gross amounts, VAT, and the payment reference.
3. Match the supplier to an existing Fortnox vendor record.
4. Create the supplier invoice through the SupplierInvoices resource with the supplierinvoice scope.

Because the API is OAuth2-based, your integration authenticates as a connected app with the scopes it needs, and Fortnox governs what that app may read or write. This keeps the automation auditable: every created invoice has a clear origin, and you control which fields your flow populates versus which a human confirms before posting.

The no-webhook problem: why you need polling

Here is a design detail that catches out many first-time integrators. The Fortnox API has no webhooks. Fortnox will not push a notification to your system when a new supplier invoice appears or an existing one changes. That means an external integration cannot simply sit and wait to be told something happened.

Instead, you must poll — query the API on a schedule and compare what you find against what you already know. If your flow needs to react to invoices that arrive in Fortnox by other routes (for example, ones created by Fakturatolkning or by staff directly), it has to ask, repeatedly, "is there anything new?"

Polling is perfectly workable, but it shapes your architecture:

• Choose a sensible interval. Every few minutes is usually plenty for accounting workflows; there is rarely a need to hammer the API every few seconds.
• Track state. Keep a record of the last invoice or timestamp you processed so each poll only handles genuinely new items.
• Respect rate limits. Frequent polling across many clients adds up. Back off gracefully and handle throttling responses.
• Make processing idempotent. If the same invoice appears in two consecutive polls, your flow must not create it twice.

None of this is a reason to avoid the Fortnox API — it is simply the reality of building on it. If a tool or agency tells you their Fortnox integration receives instant push notifications, treat the claim with caution and ask how it actually works.

E-invoicing and PEPPOL into Fortnox

Not every supplier invoice arrives as a PDF or a photo. A growing share are structured electronic invoices exchanged over networks such as PEPPOL, where the data is machine-readable from the outset and no OCR is needed at all. A true e-invoice already carries clean, structured fields — which is exactly what OCR is trying to reconstruct from an image.

For Fortnox, e-invoicing and PEPPOL connectivity are commonly handled through partners — Qvalia is one example — rather than being something you would typically build yourself from scratch. If a meaningful portion of your suppliers can send e-invoices, routing those through an e-invoicing partner and reserving OCR for the documents that genuinely need it is usually the cleaner split.

In practice, most bookkeepers end up with a blend: structured e-invoices where suppliers support them, native Fakturatolkning for standard Swedish PDFs, and a custom OCR flow for the awkward remainder. The aim is not to force everything down one path but to send each document type down the route that handles it best.

Native interpretation vs a custom OCR flow: when each wins

This is the decision most teams are really trying to make, so let us be honest about it. Fakturatolkning is a strong native option, and for many Swedish businesses it is the right default. A custom flow is not automatically better — it wins in specific situations.

Native Fakturatolkning tends to win when:

• Your invoices are mostly standard Swedish supplier PDFs.
• You want everything inside Fortnox with minimal moving parts.
• Per-invoice interpretation fees are acceptable for your volume.
• You would rather not build or maintain an integration.

A custom OCR flow tends to win when:

• You want to avoid per-invoice interpretation fees at higher volumes, where those charges add up.
• You handle sources Fakturatolkning does not cover well, such as receipts, photographed slips, or non-standard document layouts.
• You need to apply your own vendor-matching logic — rules, fuzzy matching, or lookups against your own reference data.
• You run one pipeline across several accounting systems, so the same flow can feed Fortnox alongside other tools rather than being locked to one vendor.

That last point matters for bookkeeping practices with mixed client software. If some clients are on Fortnox and others elsewhere, a single OCR pipeline that targets each system's API can be far tidier than juggling a different native add-on per client. The same reasoning applies when you compare setups across platforms, as we do in OCR invoices into Visma eAccounting.

The pragmatic answer is often "both". Use Fakturatolkning where it shines and a custom flow for the cases it was never designed to handle.

Mistakes to avoid (OCR/invoice-number duplicates, new-vendor matching)

Automating supplier invoices removes a lot of tedious keying, but a few predictable mistakes can undo the benefit. These are the ones worth designing against from the start.

Duplicate invoices from OCR and invoice numbers

The most common failure is booking the same invoice twice. It happens when a document is processed by two routes — say Fakturatolkning and a custom flow both pick it up — or when polling reprocesses an item. Guard against it by checking for an existing record using a stable identifier such as the supplier plus invoice number, and by treating the OCR payment reference as an additional signal. Make your create step idempotent so a repeated attempt updates or skips rather than duplicates.

New-vendor matching

OCR can read a supplier's name perfectly and still fail to match it to the right Fortnox vendor, because the same company may appear under slightly different names or none at all. Decide in advance what your flow does when it cannot find a confident match: park the invoice for human review rather than guessing, or create a new vendor only under controlled rules. Silent, incorrect matching is worse than an honest "needs review" flag.

Trusting amounts and VAT blindly

Field-level OCR errors on amounts or VAT are rare but costly. Where you can, cross-check that lines sum to the stated total and that VAT is internally consistent before posting. A simple arithmetic sanity check catches a surprising share of misreads.

Ignoring rate limits and failures

Because you are polling, transient errors and throttling are a normal part of life against the API. Build in retries with back-off and clear logging, so a temporary hiccup does not silently drop an invoice or, worse, create a partial record.