Who Decided That Transaction Could Post?

Diagram: an oven only turns raw transactions into books with no written rule, no memory and no record; with a mill, a rule you wrote decides whether a transaction posts or waits for a person, and each call leaves a record.

A vendor shows up in three different accounts by December.

Nobody changed the rules. Each time the bookkeeping tool looked at that vendor, it picked the category that looked right that week. In March the team bookkeeper decided where that vendor belongs, and nothing remembered the decision. By year-end the same vendor lives in three places, and the profit-and-loss report quietly stops meaning what it says.

Here is what that looks like in our own QuickBooks Online developer tenant books showing demo data. On October 5 a bank line read “wire transfer in, Acme Corp, invoice 2044.” The first call treated it as a customer payment on that invoice. Then the checks ran, and neither the invoice nor the customer existed in the books. The call was replaced, with a note saying why. The owner reviewed it, agreed income was right, and wrote one line: none exist, direct income is correct, client question logged. Three rows, one transaction, and anyone can read how it got there.

That is the failure that doesn’t announce itself. The category is plausible, so nobody questions it. The trouble starts when a tax preparer asks why a transaction sits where it does, and nobody can say what decided it.

Oven without a mill

Many “AI bookkeeping” products are an oven. They take whatever is already in QuickBooks and categorize it. What they skip is the mill: the part that decides what is allowed to post, keeps the decision, and can explain it later.

Picture the business as a bakery. Raw transactions are the grain. The mill turns grain into flour, which is books you can defend. An oven with no flour just bakes what it is handed. The bread, meaning the pricing call, the loan application, the conversation with your preparer, comes after.

Diagram: an oven only turns raw transactions into books with no written rule, no memory and no record; with a mill, a rule you wrote decides whether a transaction posts or waits for a person, and each call leaves a record.

Three ways it goes wrong without a mill

The first is a confident guess about something the tool doesn’t understand. “Microsoft 365” gets filed as software and left there, in a business where different software lines belong in different accounts if you want to see which customers make money.

The second is no memory. What was right in March drifts by October, because the tool doesn’t know what your bookkeeper already decided.

The third is no trail. When your preparer asks “why is this here?” and no record shows what decided it six months ago, you have an audit problem, and it lands on the owner.

A rule you wrote decides

The fix is not a smarter tool. It is a written rule that decides what posts on its own and what waits for a person.

Here is how that works in our practice. A model may propose a category. It doesn’t approve anything. A policy, written in plain language first and then in a policy language the system can run, decides whether a transaction posts by itself because it matches the rules, or goes to a review queue because it falls outside them. Your written policy is the authority, not the vendor’s defaults and not the model’s confidence.

Each decision leaves a record: what was proposed, which rule fired, who approved or overrode it, and when. When your preparer asks why, the answer is a row you can read, not a recollection.

If you swapped “the tool” for “a black box” in that paragraph, it would be a different sentence, and that is the point. Someone wrote the rule, someone can read it, and someone is accountable when it changes.

Flow diagram: the model proposes, a rule you wrote decides, transactions inside the rules post to the books, those outside wait in a review queue, and each call leaves a record.

What it doesn't do

By design, the rule acts where the accounting system authorizes its use. Bank-feed lines aren’t visible to us as things we can act on until they post, so a gate in front of the feed isn’t something we can honestly claim. Our gate sits where we create the entry, and as a review queue for what posted before the rule saw it. We would rather tell you which positions are real than draw a diagram where it works everywhere.

Bills have a similar gap. Some vendors email an invoice, and some send just a note saying it’s ready to download from a portal. Those get scripted retrieval where the vendor allows it and a queue where they don’t, because “bill not yet retrieved” is itself something an auditor wants to see.

And a rule doesn’t decide what your business should do. It decides what posts and why. The decisions the books are supposed to inform, which customers to keep and which bets to place, are still yours.

If your tax preparer asked why one of last quarter’s transactions sits where it does, who would you ask?

If you’d like to see where your own books stand before spending anything, the no-obligation Tax Ready Assessment scores them and names the biggest gaps. The full argument is in the Tax Ready Bookkeeping + AI Stack whitepaper.

Scroll to Top