How the AI in Books works
What the automation does, the boundary it will not cross, why ambiguity becomes an exception rather than a guess, and how machine work stays attributable.
ConceptFor Business owners, Bookkeepers, Firm staff, Portal clients
The operating principle
Automation in Books acts where it can be deterministic and stops where it cannot. That single rule explains everything else about how it behaves.
A payment that exactly matches one open bill from a known vendor is not a judgement call — it is a lookup, and automation completes it. A payment that could plausibly settle three different invoices is a judgement call, and automation stops and asks. The alternative — picking the most likely and posting it — produces books that are usually right, which is not a standard accounting can work with.
What it does
| Task | What automation contributes | What stays human |
|---|---|---|
| Document intake | Reads bills, invoices, receipts, and statements; extracts vendor, dates, amounts, and lines. | Confirming the extraction and the coding before it posts. |
| Transaction categorization | Proposes coding based on your own history, with a confidence signal. | Confirming, correcting, and deciding anything new. |
| Matching | Matches payments to open bills and invoices where the match is unambiguous. | Resolving ambiguous or partial matches. |
| Reconciliation | Proposes which lines cleared. | Ticking the statement and locking it. |
| Close support | Suggests checklist items based on what your books actually contain. | Deciding what the close requires and signing it off. |
| The coworker | Answers questions about your books and carries out operations you ask for. | Asking, and reviewing what it did. |
What it does not do
- Post into a locked period. It becomes an exception instead.
- Invent an account, a vendor, or a customer that does not exist.
- Guess at an ambiguous match to clear a queue.
- Approve anything that policy requires a human to approve.
- Delete or edit posted history — no actor can.
- Decide accounting policy. Whether something is a repair or a capital improvement is a judgement about your business.
Everything is attributable
Machine work is recorded in the audit trail with the same specificity as human work: an actor, a timestamp, and before-and-after values. On list screens, the Source column shows which records came from automation.
This means you can always answer the question "did a person decide this?" — and it means a correction to machine work is a normal reversal, visible and reviewable like any other.
Common questions
You can set automation to propose everything and post nothing, so every item passes through human review. Most teams start there and relax it for the categories where the proposals prove reliable, which is a reasonable way to build confidence.
The same as when a person does: reverse and re-post. The original, the reversal, and the correction all remain visible. Nothing about machine error requires special handling.
See alsoCorrecting a posted entry
Coding proposals improve as your history grows, because they are grounded in how you have actually coded that vendor. That is also why the first few weeks need more review than the months that follow.
No. Your data is used to answer your questions and do your work. See the data article for what is sent where and why.
See alsoAI and your data
Was this useful?