Automate Purchase Invoice Data Entry into SmartAccounts with OCR

Does SmartAccounts have native OCR?

No. SmartAccounts, an Estonian accounting system used across the Baltics, does not include its own optical character recognition. There is no built-in feature that reads a scanned PDF or photographed invoice, pulls out the supplier, date, net, VAT and total, and drops a draft purchase invoice into your books. If someone tells you the platform "has OCR", they are almost certainly describing an integrated third-party document capture tool rather than a native feature.

This matters because the marketing around modern accounting software often blurs the line. Plenty of systems bolt on capture through a partner and present it as one product. SmartAccounts is honest about relying on external document capture, typically Envoice or Finbite, to turn documents into structured data. So the real question is not "how do I switch on OCR in SmartAccounts?" but "which capture path should I use to feed it, and where does automation actually help?"

How OCR data reaches SmartAccounts: the API key and purchase invoices

SmartAccounts exposes an API, and this is the doorway for any custom automation. Once a document has been read, whether by an off-the-shelf tool or by your own model, the extracted fields need to become a purchase invoice inside SmartAccounts. The API is how you create that record programmatically instead of typing it in.

To use it, you generate an API key in the account's Settings. SmartAccounts issues a public and private key pair that authenticates your requests. Anyone building an integration, or an accountant authorising a tool on their behalf, should treat these keys like passwords: store them securely, never paste them into a public place, and rotate them if you suspect exposure.

Public documentation for the individual endpoints is limited, so we will describe this at a high level rather than invent method names. Broadly, the API lets you create purchase invoices, and you would map your captured fields, supplier, invoice number, date, line amounts, VAT rate and totals, onto the fields SmartAccounts expects. For the exact endpoint paths, request format and any current limits, confirm directly with SmartAccounts support before you build. Features and API details change, and it is far cheaper to check first than to rework a live integration.

If you are weighing OCR approaches in general before committing to any one accounting system, our overview of OCR for accounting covers the moving parts, accuracy, review, VAT handling, that apply whatever your books run on.

A ready-made route: Envoice / Finbite document capture

The lowest-effort path is to use a capture tool that already integrates with SmartAccounts. Envoice and Finbite both sit in front of your accounting system, receive documents, read them, and pass structured purchase invoices through. You forward supplier PDFs to a dedicated inbox or upload them, the tool extracts the data, a person checks it, and the approved invoice flows into SmartAccounts.

For many small businesses and bookkeepers this is genuinely the sensible option. You get:

• No development. The integration is maintained by the vendor, so you are not writing or debugging code.
• A built-in review screen. These tools present the extracted fields next to the original document for a human to confirm.
• Predictable onboarding. Setup is a configuration task, not a build project.

The trade-offs are worth naming honestly. Ready-made tools usually charge per document or per user, which adds up as volume grows. You work within the vendor's extraction rules and field mapping rather than your own. And if you run several accounting systems or want one consistent pipeline across clients, you end up managing multiple capture subscriptions with slightly different behaviour. For a single company with steady volume, none of that may bother you. For a growing practice, it starts to.

E-invoicing and Peppol (0191 IDs)

Not every invoice needs OCR at all. The cleanest supplier document is the one that never becomes an image in the first place. SmartAccounts supports Peppol e-invoicing, where invoices arrive as structured electronic documents rather than PDFs or paper, commonly through Finbite as the access point.

In Estonia, a Peppol participant ID typically uses the 0191 scheme, which pairs with the Estonian business registry code. So a company is addressed on the Peppol network by its registry code under that scheme, and a supplier who can send Peppol invoices can deliver straight into your capture flow with the data already structured. There is nothing for OCR to guess because the net, VAT and totals arrive as machine-readable fields.

Where you can get suppliers onto Peppol, prefer it. E-invoices are more accurate than any OCR result because no character recognition is involved, and they cut the review burden considerably. Realistically, though, you will not convert every supplier. Peppol handles the invoices that can be sent electronically; OCR handles the long tail of PDFs and scans from everyone else. A good setup uses both, routing structured e-invoices one way and captured documents another, then landing them in the same place in SmartAccounts.

The review workflow and vendor lookup

Whichever route you choose, keep a human approval step. OCR is good and getting better, but it is not perfect, and a wrong VAT rate or a transposed total flows straight into your VAT return if nobody checks. The point of automation here is to remove typing, not to remove judgement.

A sound review workflow looks like this:

1. Capture. The document is read and the fields are extracted, either by a ready-made tool or your own OCR flow.
2. Match the vendor. Look the supplier up against the Business Registry using its registry code so you attach the invoice to the correct, verified counterparty rather than a fuzzy name match. This also catches typos and near-duplicate supplier records.
3. Confirm the numbers. A person checks net, VAT and total against the original document, with anything low-confidence flagged for closer attention.
4. Post. The approved purchase invoice goes into SmartAccounts, via the capture tool's integration or via the API.

Matching on the registry code, rather than the free-text company name, is the small detail that saves the most cleanup later. Names vary, abbreviations creep in, and two spellings of the same supplier quietly fragment your reporting. A registry code does not.

When a custom OCR flow pays off (mistakes to avoid)

With no native OCR, you have two practical routes: a ready-made capture tool like Envoice or Finbite feeding SmartAccounts, or a custom OCR flow that reads documents and posts purchase invoices through the API. A custom flow is not automatically better. It earns its keep in specific situations:

• One pipeline across systems. If you run SmartAccounts alongside other accounting or ERP systems, a single custom flow can feed them all with consistent logic, instead of a separate subscription per platform.
• Your own review rules. You decide the confidence thresholds, the approval routing, and how vendors are matched, rather than living inside a vendor's fixed workflow.
• No per-document fees. At higher volumes, paying per invoice can outweigh the cost of building and running your own flow.

The mistakes to avoid are the same ones that sink many capture projects. Do not remove the human check to save a few seconds; the errors it catches are the expensive kind. Do not invent API behaviour, confirm the real endpoints and limits with SmartAccounts support before building. Do not match suppliers on name alone when a registry code is available. Do not force Peppol-capable suppliers through OCR when a structured e-invoice is cleaner. And do not build a custom flow for a single company with modest, steady volume when a ready-made tool would do the job at lower total effort.

If your books already run on a different Estonian system, the same principles apply with a different destination; see our companion piece on getting OCR invoices into Merit Aktiva for a close comparison.