Automating Exact Online with AI: A Practical Blueprint

Yes, and the ERP stays where it is. Exact Online publishes a REST API, and every workflow described here is built on it. The work splits into two halves that behave very differently. The deterministic half reads and writes records through the API and either succeeds or fails loudly. The AI half turns material that was never structured, supplier invoices above all, into fields the API will accept.

Operations buyers ask about scope before they ask about price. The enquiries that reach us in this category share a shape: Exact Online holding the ledger, Microsoft 365 and OneDrive holding the files, Excel doing whatever the ERP reports badly, and a steady arrival of PDF documents that somebody retypes by hand. The requirement behind them is always the same one. Reduce manual data entry while keeping exception handling and manual review wherever information cannot be reliably identified. That requirement, rather than the API, is what decides the architecture.

One useful test of whether an automation partner understands APIs is whether they publish any. aiside.ee runs an MCP server at /mcp with two tools an agent can call, a lead API whose GET request returns its own schema so a machine can learn the format without guessing, and a deterministic readiness API behind the checker on our homepage. The wider pattern is covered in our guide to AI back-office automation for smaller companies.

Four properties of the Exact Online API, all of them set out in Exact's own developer documentation, decide the architecture before anyone writes business logic. Authentication uses the OAuth 2.0 authorization code flow with short-lived access tokens and a refresh token that rotates every time it is used. Calls are scoped to a division, so the division code belongs in every request and in every record you store on your side. Rate limits are enforced per application and per division, on both a per-minute and a daily basis. And the sync endpoints expose a timestamp cursor, which is what makes incremental reads possible without re-pulling the whole dataset.

The practical consequence of the last two is that you cannot re-pull the full order book on a schedule and hope the limits absorb it. Store the last timestamp you received, ask only for what changed since then, and keep the Exact record GUID as your join key so that re-running a job updates rather than duplicates. Webhook subscriptions can push change notifications, which shortens the delay between an event and your reaction. Treat those notifications as a signal to fetch, never as the data itself, because a webhook that arrives out of order or twice is normal and a job that trusts its payload will write nonsense.

Log every call with its division, endpoint, status and duration. When finance asks in November why a September invoice was posted the way it was, that log is the answer.

A sales order sync is an incremental read from Exact Online followed by an upsert into a named table in a workbook on OneDrive or SharePoint, written through the Microsoft Graph API, the same interface behind the rest of the finance workflows that run inside Microsoft 365. The upsert is the part that matters. Key every row on the order GUID plus the line number, so running the job twice produces the same sheet rather than a second copy of everything. Write into a named table rather than a cell range, because a table survives someone inserting a column and a hardcoded range does not.

Add two columns beyond the fields that were requested: the timestamp of the last successful sync, and the status the record held in the ERP at that moment. Together they answer the question people otherwise ask over the phone, which is whether the sheet is current.

Decide direction before the build, not during it. Excel works well as a window onto the ERP and badly as the place the truth lives. The moment people start editing the sheet and expecting Exact Online to follow, you have created a second system of record and a reconciliation problem that did not exist before. Two-way sync is buildable, but every writable field needs an explicit rule for which side wins on conflict, and each of those rules costs more to specify than the field is usually worth. Start one-way. Add write-back for the two or three fields that genuinely need it, with validation on the way in.

This is the workflow where AI earns its place, because supplier invoices are unstructured by nature and every supplier lays them out differently. The mechanics of extracting fields from a supplier invoice PDF are the same whichever ERP receives the result, and what follows is the Exact Online version of them. The pipeline has five stages. A watcher picks up new documents from a mailbox folder or a OneDrive folder. A vision-capable model reads each page and extracts supplier identity, invoice number, invoice and due dates, currency, net amount, VAT per rate, gross total, line descriptions and any purchase order reference. The supplier is then matched to an Exact Online account by VAT number or IBAN before name, because registered names drift and payment details rarely do. The general ledger account and cost centre are suggested from that supplier's own posting history rather than from the model, since history is evidence and a model guess is not. Only then does the entry get created, with the original PDF attached to it so the audit trail keeps the source document.

Three deterministic gates run before any posting. Line amounts plus VAT must equal the stated total to the cent. The supplier and invoice number pair must not already exist, which is what stops the same invoice being paid twice after it arrives by email and again by post. The currency and VAT rate must be ones the division actually uses. A document that fails any gate never reaches the ledger, regardless of how confident the extraction was.

Reconciliation is a matching cascade, and it should be written as one rather than as a single clever rule. The first pass matches the structured payment reference, when the invoice carried one, straight to the open receivable. The second matches an exact amount together with the counterparty IBAN. The third scores a candidate on name similarity, amount proximity and how close the payment date sits to the due date, and only accepts the match above a threshold you set deliberately.

Three cases break naive matchers, and all three are ordinary in a real ledger. A customer pays part of an invoice. A customer pays one round sum covering six invoices, one of which has a credit note against it. A payment arrives before the invoice has been posted at all. Decide the handling for each of these before the build starts, because the code is easy and the policy is not. Set a write-off tolerance in cents for rounding differences and bank charges, and log every automatic write-off with the amount and the reason, so the tolerance can be audited later.

One honest caveat about the source data. A bank notification email is a weaker input than the bank's own statement file, so reconciling payments out of notification emails needs defences the statement route does not. Emails get reformatted without warning, arrive out of order, and sometimes omit the reference field entirely. If the bank can deliver camt.053 or a comparable structured export, build the reconciliation on that and treat the emails as an early signal rather than as the record. Whatever does not match lands in a queue with the three highest-scoring candidates and the reason each was rejected.

Delivery planning starts as a straightforward query and becomes useful only when it produces exceptions. The job reads open sales order lines with their promised delivery dates, joins current free stock, then groups by ship date, delivery address and carrier. Output goes to a dated dispatch list that the warehouse can work from, in whatever format they already use.

The flags matter more than the list. Lines whose promised date cannot be met given free stock and supplier lead time. Two orders going to the same address on consecutive days that should have travelled together. Orders whose delivery date has already passed and that nobody has closed. Each flag is a question that a person answers in seconds and that currently nobody asks at all, because scanning for them by hand across a few hundred open lines is not realistic.

This is the workflow where automation stops being extraction and starts encoding business rules, and those rules usually live in one experienced person's head. How many days before a promised date does a line need to be picked. Which customers are never split across two deliveries. Which supplier lead times are real and which are optimistic. Write these down before the build, in plain sentences, and have the person who currently makes the decisions read them back. That document is more valuable than the code, and it takes longer to produce than the code does.

Month-end archiving is a scheduled job with one non-obvious requirement: it has to verify itself. The straightforward part pulls the period's documents from Exact Online and from the mailbox, renames each one to a deterministic convention covering year, month, document type, supplier and document number, and files them into a dated folder tree in SharePoint or OneDrive. It then writes an index file listing every document with its ERP reference and a direct link.

The count check is the step worth insisting on. Count the documents in the archive for the period and compare that count against what the ERP says exists for the same period, by document type. If the numbers disagree, the job fails loudly and names the missing references rather than reporting a green tick. An archive that nobody verifies is a folder with files in it, and its value only becomes testable during an audit, which is the worst moment to discover the gap.

Two details worth settling early. Keep the original file bytes, not only the extracted data, because the extracted fields represent one interpretation and the document is the evidence. And apply retention as a policy the job enforces rather than as a task somebody performs, with the retention period recorded next to the folder so the rule survives the person who set it.

One well-defined workflow, such as purchase invoice creation from PDFs, is typically a one to three week build. Systems covering several workflows are quoted per project, because the cost sits in the exception rules rather than in the API calls. Our published prices:

Now the limits. Document-driven workflows do not reach full straight-through processing, so treat a promise of one hundred percent automatic posting as a reason to ask harder questions. Agree two numbers before the build starts: the exception rate you accept per workflow, and the minutes a single exception is allowed to take. The second of those is decided by how the review queue is designed rather than by the model. Measure both from week one. Supplier mappings accumulate as reviewers correct fields, so the exception rate should fall month over month. If it does not, something in the design is wrong, and month one is a much cheaper place to find that out than month six.

Ownership is settled in the same conversation. The source code, the infrastructure and the rights stay with the client, and the extraction model sits behind an interface so it can be swapped without a rebuild. If a company thinks it is too small for this, the counter is the single-workflow start: automate one process, measure the hours it returns, then decide about the second. The same discipline applies on the public side of the business, where machine-readability decides whether an assistant recommends you at all and where you can test the current state yourself in half a minute with the free readiness check.