What to expect from an accounting software integration

An integration moves extracted expense data from where it was captured into where your books live. What it does not do is decide anything — the account mapping, the tax treatment and the approval remain yours, and an integration that appears to handle them is applying defaults you didn’t choose.

Connecting two systems is easy. Knowing what happens when they disagree is the part worth understanding before you rely on it.

Question 1: does it create drafts or post entries?

The single most important question, and the answer is not always obvious from the marketing.

Drafts land in a review area, where you can correct, match and approve before anything becomes a ledger entry. This is what you want. It preserves the boundary between proposed and booked.

Direct posting writes to the ledger immediately. Faster, and it means extraction errors become entries you have to amend rather than drafts you can edit. Amendments leave a trail, which is correct behaviour, but a ledger full of amendments for avoidable reasons is noise in the record.

If a tool posts directly and can’t be configured otherwise, understand that you’ve accepted its extraction accuracy as your posting accuracy.

Question 2: does the image travel with the data?

Extracted fields without the source document are unsupported numbers. The receipt image is the evidence, and it should end up attached to the entry in your accounting system — not left behind in the scanning tool.

Why it matters beyond tidiness: your accounting records need to be complete on their own. If the evidence lives in a separate product on a separate subscription, then cancelling that subscription detaches your books from their support.

Check specifically: is the original image attached, or a link to it? A link to a system you might stop paying for is not the same as an attachment.

Question 3: how does it map categories?

Your chart of accounts is specific to you. The scanning tool has its own category names. Something has to translate.

The good version: an explicit, editable mapping you can read — this category goes to that account. The bad version: an automatic guess based on category-name similarity, applied silently, which works until it puts six months of a material expense in the wrong account.

Set this up deliberately at connection time. It’s ten minutes and it’s the difference between an integration that saves work and one that generates reclassification work.

Question 4: what wins when both sides change?

Two systems holding the same record will eventually disagree. You need to know the rule.

Concretely: you correct a total in the accounting system, and the scanning tool re-syncs with its original value. Does it overwrite your correction? Create a duplicate? Flag a conflict? Do nothing?

The best answer is one-directional flow — data moves one way, corrections are made upstream, and nothing writes back. Two-way synchronisation between systems that both allow editing is a source of surprises that tend to surface at reconciliation.

Question 5: what happens to duplicates?

If receipts flow in from scanning and transactions flow in from a bank feed, both describing the same expense, something must reconcile them. Ideally that happens before posting, so one entry emerges carrying both the amount and the document.

Ask what the integration does when it encounters a transaction that already has an entry. Matches it? Creates a second? An expense list with everything doubled is a recoverable problem, but only if you notice before it becomes a quarter of data.

Question 6: what does disconnecting look like?

Worth knowing on day one. If you stop using the scanning tool: do the entries it created remain intact, do the attached images remain, and can you export the full history including originals?

Run the export before you depend on the integration. Open a few of the exported images with something else. This is a ten-minute check that tells you whether your records are portable or hostage.

Failure modes these questions prevent

Silent misclassification — the category mapping was a guess and nobody read it. Caught by question 3.

Doubled expenses — two inbound sources, no matching. Caught by question 5.

Overwritten corrections — someone fixed a figure and a sync undid it. Caught by question 4.

Unsupported entries — the ledger has amounts and the documents live elsewhere. Caught by question 2.

Amendment noise — extraction errors became postings rather than drafts. Caught by question 1.

Lock-in discovered at the worst moment — during a migration. Caught by question 6.

None of these is exotic. They’re the ordinary consequences of connecting two systems without agreeing which one is authoritative for what.

A reasonable setup

For most small businesses: scanning captures documents and extracts fields, an integration pushes drafts one way into the accounting system with the image attached, category mapping is explicit and reviewed, corrections happen upstream in the scanning tool, and matching to bank transactions happens before posting.

That arrangement has one authoritative source per stage and no place for the two systems to disagree — which is a better description of a working integration than any feature list.