Estonia is a strange market for accounting software. The statutory plumbing is better than almost anywhere: e-MTA takes machine submissions, the Business Register accepts structured annual reports, bank data is available over PSD2 APIs, and the state gives micro companies a free bookkeeping tool. The local vendors have built tightly against that plumbing for two decades.
What Estonia does not have much of is the layer above the plumbing: the part where a three-person finance team closes five entities in four countries, chases 400 unreconciled bank lines, answers the board's question about gross margin by channel, and files KMD, TSD and VD on the 10th and 20th without anyone working a weekend.
That gap is what "AI accounting software" is being sold into in 2026. This guide is about telling the versions apart.
What the Estonian stack actually solves
Start with an honest map, because the local tools are good at what they were built for.
Merit Aktiva is a clean, cheap, well-localised bookkeeping system for small and mid-size Estonian companies. VAT handling, KMD generation, payroll integration, bank imports, e-invoice channels. If you are a 15-person company with one accountant, it is hard to beat on price and fit.
Directo is an ERP, not a bookkeeping tool. Its centre of gravity is retail, wholesale and logistics: stock, purchase orders, POS, warehouse, project billing, with Estonian statutory reporting attached. Companies moving inventory pick it for a reason.
Around them: Standard Books, SmartAccounts, SimplBooks, Erply Books, and the state's e-arveldaja for the smallest entities. On the document side, Finbite, Telema, Omniva, Envoice and CostPocket move e-invoices and receipts. Most have some form of machine-learning document recognition and have had it for years.
Then there is the other half of the market that this guide is really for: Estonian companies in the 50 to 200 employee band running Microsoft Dynamics 365 Business Central or NetSuite, usually because they have a Nordic parent, a foreign investor, or subsidiaries in Latvia, Lithuania, Finland or Sweden. Those systems handle multi-entity and multicurrency properly and handle Estonian statutory output badly, or through a localisation partner and a stack of Excel.
What changed in 2025 and 2026
Four shifts are pushing Estonian finance teams to re-examine their stack this year.
VAT is 24%. The standard rate moved from 20% to 22% in January 2024 and to 24% from 1 July 2025. Two rate changes inside eighteen months means every contract, price list, recurring invoice template and partially-delivered project needed a cutover rule, and every historical period needs to reconcile against a different rate. If your system stores rates as configuration rather than as effective-dated data, you have felt this.
E-invoicing became demand-driven. Since 1 July 2025, a buyer registered in the Commercial Register as an e-invoice recipient can require machine-readable e-invoices from its suppliers. This is not a full B2B mandate like Poland's or Germany's roadmap, but the practical effect is that PDF-by-email is now a customer-service decision rather than a default. Structured invoices in and out, on Peppol BIS or the Estonian EVS 923 format, are becoming table stakes.
Distribution-based CIT keeps confusing group reporting. Estonia taxes distributions, not retained profits, at 22/78 on net distributions since 2025 (the reduced 14/86 regular-distribution rate was abolished). This is elegant locally and awkward in a group: a Finnish or Swedish parent's consolidated tax note, deferred tax logic and dividend planning all have to model an Estonian entity that carries no current tax charge on profit. The reconciliation between local books and group reporting is where hours disappear.
The AI layer arrived in every vendor's release notes. Every ERP and bookkeeping vendor now ships something branded as AI. Almost all of it is one of the three things below, and the difference between them is worth more than any feature list.
Three different things called "AI accounting software"
Tier 1: document capture. OCR plus a classifier that reads a supplier invoice, extracts the fields, guesses the account and cost centre, and puts a draft in a queue. This has existed in the Estonian market since well before large language models and it works. It is genuinely useful, and it saves maybe 20% of an accounts-payable clerk's time. It does not touch the close, reporting, or anything requiring judgement across more than one document.
Tier 2: a copilot bolted to a UI. A chat panel inside the ERP that can answer questions about data on screen, draft an email, or explain a variance. The constraint is structural: the copilot is scoped to the vendor's own data model and its own screens. Ask it to reconcile a Swedbank statement against a Directo sales ledger and an LHV card feed and it cannot, because two of the three systems are outside its walls.
Tier 3: an agent layer that reads across systems and writes into the ledger under controls. The agent has read access to bank feeds, the ERP, the document store, the payroll system and the tax authority's data. It composes work across all of them, produces a proposed set of entries or a filled declaration, and posts through the same approval path a human accountant would use. Gartner's read on enterprise finance AI is consistent with what we see in the market: the gap is not model quality, it is multi-entity support, integration and governance.
Tier 3 is where the real hours are, and it is also where most vendors are not, because it requires being an ERP-grade system of record and an AI client at the same time.
What an agent layer has to prove in Estonia specifically
If you are evaluating anything that claims to run finance work for an Estonian entity, these are the concrete questions. They are boring on purpose. Boring questions separate products from demos.
- KMD and KMD INF. Can it generate the VAT return and the line-level annex, applying the counterparty threshold rule correctly, and reconcile the annex back to the ledger before submission? Splitting a partially deductible purchase and getting it into the right INF rows is the actual test.
- TSD. Monthly payroll, fringe benefit and distribution declaration by the 10th, with correct handling of the CIT-on-distribution rows when a dividend is paid.
- VD and Intrastat. EU sales list and, above the thresholds, statistical reporting, both sourced from the same transaction set as VAT.
- Annual report to the Business Register. Structured submission in the register's taxonomy within six months of year end, including the notes, not just the primary statements. Ask to see a generated report, not a screenshot.
- Estonian bank formats and feeds. LHV, Swedbank, SEB, Luminor, Coop, plus Wise and Revolut for the e-resident-founded companies. ISO 20022 camt/pain files as a fallback where an API is unavailable.
- E-invoice channels. Send and receive over Peppol and through the local operators, with the inbound structured invoice mapped to a purchase entry without a human retyping it.
- Estonian-language source documents. Supplier invoices, contracts, board minutes and Maksu- ja Tolliamet correspondence arrive in Estonian. Language handling is a solved problem for modern models; ask anyway, and ask what happens with a scanned Estonian PDF that has no text layer.
- Multi-entity and multicurrency close. Intercompany elimination, FX revaluation, a consolidated pack that a Nordic parent will accept, and a defensible bridge between the Estonian statutory accounts and the group's IFRS numbers.
- Audit trail. Every AI-originated posting traceable to the instruction, the source document, the validation rules it passed and the human who approved it. This is what your auditor will ask about in the first meeting after you deploy anything agentic.
How Artifi approaches this
Artifi's line is "enabling Claude to run your finance function," and the mechanism matters more than the line.
The system is a real ledger with real workflows underneath, and Claude sits on top of it as the interface. Agents do not free-hand journal entries. Every write, whether it originates from a human in the platform or from an agent, goes through one governed gateway: validation, then a risk-lane approval step, then an audit trail entry. Reads are role-scoped. A junior AP agent cannot see payroll. The reason to build it this way is not caution for its own sake; it is that a finance system whose entries cannot be explained to an auditor is not a finance system.
Three things that follow from that architecture and are relevant in Estonia:
Statutory work ships as plugins, not as core releases. Estonian filings are implemented as Claude plugins over the platform's data. That is how a jurisdiction-specific requirement gets delivered in weeks rather than waiting on a vendor roadmap. The live Estonian statutory filing plugins are the working example, and the same pattern covers a Latvian or Lithuanian subsidiary when you acquire one.
MCP connectors are the integration story. Any system with an MCP connector, whether that is a billing platform, a bill-pay tool or a document archive, can feed the ledger today. Claude reads from the connector and posts through the governed gateway. There is no six-week integration project for the long tail of tools your team already uses.
The file-drop path covers what no connector does. Drop a broker statement, a bank PDF, an Estonian supplier's scanned invoice or a folder of 300 receipts into Claude. It parses, maps and imports through the same gateway with the same controls. Reports come back as Claude Artifacts, formatted PDF or Excel, or as an interactive dashboard, which means the monthly board pack is a scheduled instruction rather than a spreadsheet ritual.
Honest limits, since the checklist above cuts both ways: there is no Plaid dependency (irrelevant in the Baltics, but worth stating), no cash-basis mode, and inventory is not a strength. If you are Directo's core customer moving stock through three warehouses, Directo is the better answer for that part of your operation, and Artifi's role is the layer above it.
Running an evaluation that produces evidence
Do not evaluate on a demo. Evaluate on one closed month.
Pick a single entity and one painful workflow: bank reconciliation across two accounts, or supplier invoice processing including the KMD INF consequences. Give the vendor read-only access to real data for that scope. Ask for the output your accountant would produce, and have your accountant grade it, line by line, against what they actually did that month. Count the exceptions, not the successes.
Then look at the exceptions and ask a second question: when the agent got it wrong, was it visible? An agent that fails loudly into a review queue is deployable. An agent that fails silently into the ledger is not, regardless of its accuracy rate.
Artifi runs this as a paid pilot at €500 per month for three to six months, moving to €1,000 to €1,500 per month in production for a base plus two or three core workflows, with a one-time scoping and onboarding fee. The pilot price is deliberately low relative to the value at stake because the pilot is a test, and tests should be cheap enough to fail.
The short version
If you are under 50 people with one bookkeeper, Merit or SmartAccounts plus a good outsourced accountant is still the right answer, and no AI layer will pay for itself.
If you are 50 to 200 people with a three to eight person finance team, entities in more than one country, and Business Central or NetSuite underneath, the constraint is not your ledger. It is the manual work stacked on top of it: reconciliation, bills, consolidation, statutory filings across jurisdictions, and the reporting your investors ask for. That is the layer worth automating, and 2026 is the first year the tooling is good enough to do it with an audit trail attached.
If that describes your company, get in touch. Bring one month of real data and one workflow you hate.