Automate Invoice Data Entry into Merit Aktiva with OCR

Does Merit Aktiva have native OCR?

No. Merit Aktiva does not read scanned or photographed supplier invoices on its own. There is no built-in feature that lifts the supplier, date, totals and VAT off a PDF and turns them into a purchase invoice for you. Merit's own guidance points the same way: use an external OCR or AI tool to extract the data, then post the finished result into Merit.

This matters because it sets realistic expectations. If you are comparing accounting systems and assume OCR is included, you may be surprised. Merit is a capable Baltic accounting platform used in Estonia, Latvia, Lithuania and Poland, and it typically covers the ledger side well. Document capture, though, is a gap you fill yourself.

The good news is that Merit gives you the tools to close that gap cleanly. It has a well-documented API that Merit describes as a way of "connecting robots" to the system, and that API is exactly where extracted invoice data belongs. So the honest picture is: Merit does not do OCR, but it makes it straightforward to send OCR results in. For background on how document reading actually works, see our primer on OCR for accounting.

How OCR data reaches Merit: the Purchase Invoice API

Merit exposes a RESTful JSON API, and the endpoint that matters here is sendpurchinvoice (available in v1 and v2). You send it a structured object describing the invoice: the supplier, the invoice number and date, the currency, the line rows, and the VAT breakdown. Merit creates the purchase invoice and its ledger entries immediately.

A typical flow looks like this:

1. A supplier invoice arrives as a photo, an email attachment or a PDF.
2. An OCR or AI step reads the document and returns structured fields.
3. Those fields are mapped into the shape Merit's API expects.
4. A call to sendpurchinvoice posts the invoice and its entries into Merit.

One detail is genuinely useful for bookkeepers: the API accepts the original document as a PDF encoded in Base64, passed as an attachment object. That means you can post the extracted data and attach the scanned original to the same record, so the source document lives next to the accounting entry. When someone later questions a figure, the evidence is one click away rather than buried in an inbox.

If you are new to the idea of removing manual keying entirely, our guide on how to automate invoice data entry walks through the wider pattern before you commit to any one system.

Import options compared: API vs XML import vs e-invoice (PEPPOL) operators

The API is not the only way to get purchase invoices into Merit. It helps to see the three routes side by side, because they suit different situations.

The API (sendpurchinvoice)

This is the flexible option. It accepts data from any source, including OCR output, and it lets you attach the original PDF. It is the natural fit when your suppliers send scans, photos or plain PDFs rather than structured documents. You control the mapping, so you can handle awkward supplier formats.

XML import

Merit supports importing purchase invoices in the Estonian e-invoice XML format. This is a good fit when a document already arrives as structured XML, because no reading step is needed. It is less useful for the everyday reality of scanned or emailed PDFs, which carry no structured data to import.

E-invoice operators and PEPPOL

Merit supports native e-invoices through operators such as Telema, Finbite (Omniva) and Merit itself, with PEPPOL reachability provided through those operators. When a supplier can send a true structured e-invoice, this is typically the cleanest path: the data arrives machine-readable, so there is nothing to OCR.

In practice most SMBs need a mix. Suppliers who send e-invoices flow in through an operator; everyone else still sends PDFs and photos, and those are the ones an OCR-plus-API flow handles. The routes complement each other rather than compete.

Direct posting vs waiting for approval: the review workflow

Speed is good, but bookkeepers rightly want a check before figures hit the ledger. Merit gives you a choice of two behaviours here, and picking the right one is the single most important design decision in an automated flow.

• sendpurchinvoice creates the purchase invoice and its ledger entries immediately. The invoice is posted the moment the call succeeds.
• sendpurchorder creates a purchase invoice that is "waiting for approval", so a bookkeeper confirms it manually inside Merit before it is finalised.

For most SMBs and bookkeeping practices, the approval route is the safer default. OCR is accurate but not infallible, and a person glancing over the supplier, total and VAT before confirming catches the rare misread before it becomes a correcting entry. The extra step typically takes seconds per invoice, and it keeps a human firmly in control of the books.

A sensible rule of thumb: automate the typing, not the judgement. Let the flow extract and stage the invoice; let a person approve it.

You can also mix the two. Trusted, repetitive, low-value invoices from known suppliers might post directly, while anything unusual or above a threshold is routed to approval. That balance is a business decision, not a technical one, and it is worth agreeing before you build.

When a custom OCR flow into Merit pays off

Because Merit has no built-in OCR, a custom flow is the natural way to fill that gap. But it is worth being honest about when the effort is justified.

A custom flow typically earns its keep when:

• You process enough supplier invoices each month that manual keying is a real time cost, not an occasional chore.
• Invoices arrive as PDFs, photos or email attachments rather than structured e-invoices.
• You want the original document attached to every record for audit and review.
• You want a consistent, repeatable process instead of relying on one person's routine.

The shape of such a flow is straightforward: a photo, email or PDF triggers an OCR or AI step, the extracted fields are mapped to Merit's format, and the invoice is posted through sendpurchorder (or sendpurchinvoice) with the PDF attached. A human approval step stays in the loop for control.

If your volumes are low, or nearly all your suppliers already send e-invoices through an operator, a custom build may be overkill and the operator route alone might serve you. The value of automation scales with volume and with how messy your incoming documents are, so count your invoices before you invest.

Common mistakes (duplicate invoices, VAT rows, attachments)

Automated posting removes typing errors, but it can introduce a few new ones if the flow is careless. These are the issues we see most often, and each is avoidable.

Duplicate invoices

The most common problem is posting the same invoice twice, usually because a document was received through two channels or a run was repeated. Build a de-duplication check, typically on the combination of supplier and invoice number, before calling the API. It is far easier to block a duplicate at the door than to reverse a posted entry.

VAT rows

VAT is where OCR flows most often go slightly wrong. An invoice may mix VAT rates, include reverse-charge lines, or show rounding that does not reconcile to the penny. Make sure the extracted VAT breakdown matches Merit's expected structure and that the totals reconcile before posting. When VAT looks unusual, route the invoice to approval rather than posting it directly.

Attachments

The ability to attach the original PDF is one of the strongest reasons to use the API, yet it is easy to forget. If you skip it, you lose the audit trail that makes the whole exercise trustworthy. Confirm the Base64-encoded PDF is included on every call, and check that large files are handled without being silently dropped.

Get these three right and an automated Merit flow typically runs quietly in the background, with a person approving rather than typing.