QuickBooks Online Ready to post: why the automation skips some transactions
We look at why QuickBooks Online marks some bank feed transactions Ready to post, why others sit held for review, and how posting criteria are set.
QuickBooks Online’s redesigned banking page has given many users a label they did not ask for: Ready to post. The flag appears on bank feed transactions the software believes it can categorise on its own. Questions about it cluster around two worries. People want to know what the label guarantees, and why neighbouring transactions still read Held for review. The accepted answer on the topic walks through both. We have gone through it, and the short version is that the automation is pickier than it looks.
Which plans get Ready to post?
The feature belongs to the AI-powered banking page and to Intuit’s wider Accounting AI work. It reaches QuickBooks Online Essentials, Plus, and Advanced subscribers. Simple Start does not get it at all. That plan gap accounts for a fair share of the confusion we see reported. People on the entry tier hear about batch posting, open their own banking tab, and find none of it. Nothing is broken in that case. The plan simply does not include the feature.
The evidence behind a ready flag
Ready to post is a matcher rather than a guesser. As transactions arrive from a connected bank account, each one is weighed against two sources of evidence: transactions you have already categorised, and the standards in your posting policy. Three gates must open before the flag appears.
History comes first. The software looks for similar transactions you have posted before under the same category. Without that history, a transaction waits for your review even when the suggested category looks right. A single clear category comes second. Where two categories could plausibly apply, the item is reserved for fuller review instead of a coin toss. The extra fields your books expect come third. If you normally record a payee or customer, a class, or a location on similar transactions, the software wants a confident suggestion for that field too.
Why do some transactions stay held for review?
This is where most of the confusion resolves. Held for review is not an error state. It is the deliberate output of the gates above. A transaction needing only a category, with one confident candidate, becomes Ready to post. A transaction with a required field the software cannot fill confidently is held back and never enters the ready batch. The same applies to items with no supporting history or with rival categories. Nothing goes missing. Held items stay in the bank feed for your usual manual review.
Your criteria set the bar
You are not stuck with someone else’s defaults. The Transaction posting policy is where the Ready to post criteria live: the standards a transaction must meet before the software will batch it for you. Companies that require from or to details, classes, or locations on some or all transactions spell that out there. The automation then holds anything it cannot complete with confidence.
This is the practical fix for anyone who finds the feature too eager or too timid. Tighten the required fields and fewer transactions clear the bar. Loosen them and more move through, provided the history exists to support each suggestion. The policy is also where you decide whether a category alone is enough to post, or whether a payee must come with it.
Nothing posts without you
The label is a proposal, not an instruction. You review the batch, edit anything that needs editing, and post when satisfied. The saving lies in the batching itself: one pass over grouped transactions instead of a one-at-a-time trawl through the feed. The decision stays with you throughout.
For transactions that never qualify, nothing changes. They remain in the bank feed under the review process you already use. The automation narrows the queue. It does not empty it or act on its own.
The takeaway
Ready to post rewards consistent history more than anything else. Books with repetitive bank activity benefit most, because the matching has prior postings to lean on. Books with varied or lightly categorised history will see more Held for review, and that is by design. Set the posting policy to match what your company actually requires, and the split between the two queues starts to make sense.