Centinel's reconciliation queue and didn't-post alerts surface discrepancies between your forecast and your bank account for quick resolution.
March 15, 2026
Within the broader mechanics of how a checking account cash flow forecast actually works, keeping a checking account forecast accurate is an ongoing practice. Your balance changes, amounts vary from estimates, and new expenses appear. On Centinel's Premium tier, the matching algorithm handles much of this automatically: when Plaid delivers new transactions from your bank, the system scores each one against your saved events, and for the majority — the ones where the amount, date, category, and merchant clearly correspond to a specific forecasted event — the match is resolved silently. Your rent posted for $1,500 on the first, exactly as scheduled. Your paycheck arrived for $2,847.63 on Friday, as expected. Matched, recorded, forecast recalculated. You never see these.
But not every transaction is straightforward. A $47.99 charge posted from a merchant the system doesn't recognize. Your electricity bill posted three days later than usual and for a noticeably different amount. Your bonus that you expected to post this week never appeared in the bank feed.
These discrepancies between forecast and reality flow in two directions. Sometimes a bank transaction posts that the system can't confidently match to a forecasted event. Sometimes a forecasted event doesn't produce a corresponding bank transaction when expected. Both represent gaps between what the forecast predicted and what actually happened — and both need to be resolved to keep the forecast accurate. Centinel handles them through two distinct mechanisms: the reconciliation queue for transactions that happened but couldn't be matched, and didn't-post alerts for events that were expected but never appeared.
The reconciliation queue lives in Centinel's Transactions tab — the hub for all bank transactions delivered through Plaid and their match status. When the matching algorithm scores a transaction below the auto-match threshold, the transaction lands in the queue for your review. Each morning, Centinel notifies you of how many items are waiting.
Queue items come in two forms. Some arrive with a suggested match — the system has a best guess about which forecasted event the transaction corresponds to, but the confidence wasn't high enough to act autonomously. You see the bank transaction details (amount, date, merchant) alongside the suggested event. Others arrive with no suggestion — the confidence was too low to propose any match, which typically means the transaction is a one-time charge, a new recurring pattern, or an event that looked very different from what was expected.
For every item in the queue, you have a specific set of actions. Each one has a different meaning for the forecast and teaches the matching algorithm something different about your financial patterns.
The most common resolution. The system proposed that a bank transaction corresponds to a specific event, and you agree. You tap confirm, and the transaction is linked to the event. If the actual amount differed from the forecast estimate — your electricity bill was $100 instead of the projected $150 — the forecast recalculates with the actual amount flowing through. The event's matching profile is updated: the merchant name and category from the bank transaction are stored, strengthening the system's ability to auto-match this event in future months. An event that needed your confirmation this month will typically auto-match next month, because the system now knows what it looks like in the bank feed.
This action is designed to take seconds. The system has already done the work of identifying the most likely match — you're just validating its judgment. For a user in their first month on Premium, when several events are still building their matching profiles, confirming a handful of suggested matches might take a minute or two during a weekly review. By the second month, most of those same events will auto-match without ever reaching the queue.
Sometimes the system's suggestion is wrong. The algorithm proposed that a $9.99 charge matches your Spotify subscription, but it's actually your iCloud storage payment — a different event with a similar amount and date. You select the correct event from your list, and the match is recorded against it instead.
This correction is particularly valuable for the matching algorithm's learning loop. The incorrectly suggested event's profile is not updated with the misleading transaction data. The correctly identified event's profile is strengthened with the merchant name and category from the bank transaction. Over time, corrections like this teach the system to distinguish between events that look similar in the bank feed — two subscriptions that charge similar amounts mid-month, for instance — so it can make the right determination automatically in future months.
This is the resolution that expands your forecast to cover patterns you weren't previously tracking. A $99 charge posts to your account, and it doesn't match anything in your forecast. You notice that this was the insurance you signed up for but forgot to add to your saved cash flow events. You tap it and create a new recurring event directly from the transaction. Centinel uses the transaction's data — the amount, the merchant name, the category, the date — to seed the new event's matching profile. This means the next time this charge posts, the system already knows what it looks like and can match it automatically, often with high enough confidence to auto-resolve without ever reaching the queue in the future.
This is also the primary way Centinel helps you catch structural changes to your financial pattern. A new subscription, a new bill, a new regular transfer — these would otherwise go untracked, silently accumulating error as the forecast fails to account for a recurring outflow that's actually happening. By surfacing unmatched transactions and giving you the option to add them as new events, the queue acts as a detection mechanism for changes in your financial life that you might not have thought to update manually.
Not every bank transaction corresponds to a recurring event in your forecast. An ATM withdrawal, a restaurant meal, a one-time online purchase, a reimbursement from a friend — these are transactions that happened, that affected your balance, but that don't represent an ongoing pattern you need to track. You dismiss the transaction, and it's marked as reconciled with no event association. There's no forecast impact beyond what your balance sync already captured, because the balance already reflects this transaction's effect on your account. No matching profile is updated, because there's no recurring event to learn from.
Users can also reverse a previous match — whether it was auto-matched by the system or manually confirmed from the queue. This handles the rare case where the system matched a transaction to the wrong event and neither the user nor the algorithm caught it at the time, or where the user confirmed a match and later realized it was incorrect.
When a match is reversed, the event's matching profile is updated to reflect the correction — the misleading merchant data or category from the wrong transaction is removed — and both the transaction and the event return to an unresolved state for the user to re-resolve. In practice, unmatching should be infrequent. The auto-match thresholds are set conservatively enough that false positives are rare, and the suggested match flow gives users a chance to catch errors before they're confirmed. But its existence means the user always has final authority over how the forecast maps to reality. No match is permanent if it turns out to be wrong.
The reconciliation queue handles one direction of discrepancy: bank transactions that the system couldn't match to a forecasted event. But discrepancies also flow the other way. Sometimes a forecasted event simply doesn't produce a corresponding bank transaction when expected. Your $65 gym membership was due on the 15th, but on the 16th, no matching debit has appeared. Your Netflix subscription was scheduled for the 1st, but nothing posted.
Centinel surfaces these through the Alerts section of the app, separately from the reconciliation queue. The logic is straightforward: if a forecasted event passes its expected date and no bank transaction matches it by the following day, Centinel flags it as a didn't-post alert. The alert tells you which event was expected, what amount was projected, and that no corresponding transaction was detected.
This distinction — alerts rather than queue items — reflects an architectural choice about where different types of information belong. The Transactions tab is the home for bank transactions that actually occurred and their match status. Items that didn't occur don't belong there. The Alerts section is the appropriate surface for drawing attention to something that was expected but didn't happen.
When Centinel raises a didn't-post alert, it also immediately removes the missed event's projected occurrence from the forecast. The reasoning: if the transaction didn't post on its expected date, carrying it forward in the forecast would mean projecting an outflow that may never materialize. If the transaction does eventually post, the balance sync will capture it, and the matching algorithm will process it when it arrives.
From a didn't-post alert, you have two paths.
The first is to dismiss the alert. You're telling Centinel: "I know this didn't post, and that's expected." Maybe the payment was intentionally skipped this month, or it was charged to a different account, or you already know the billing date shifted. The alert clears, and the recurring event remains in your forecast unchanged for future occurrences.
The second is to add the expected event back to your forecast as a one-time occurrence with a new expected date. You're telling Centinel: "This is just late — it's still going to post, and I want my forecast to reflect that." You select when you expect it to post (today, tomorrow, or a custom date), and Centinel re-inserts that single occurrence into the forecast at the new date. Your recurring event template remains unchanged — this adjustment only affects the current occurrence, so future months project normally.
If the underlying obligation has changed permanently — you cancelled the gym membership, or the billing date shifted to a new day of the month — you'd handle that by modifying or deleting the event itself from your saved events, which is a maintenance action rather than an alert response.
Together, the didn't-post alerts and the reconciliation queue cover the full surface area of discrepancies between forecast and reality. The queue resolves what happened but wasn't predicted (or couldn't be matched). The alerts catch what was predicted but didn't happen. Between the two, no discrepancy goes unaddressed.
In corporate treasury management systems, both of these mechanisms have direct analogs. The reconciliation queue maps to what treasury platforms call the exceptions queue: the transactions that automated matching couldn't confidently resolve, routed to a human analyst for review. The didn't-post alerts map to what treasury teams call expected-but-missing cash flows: forecasted items that don't appear in the bank statement, which trigger investigation into whether the payment was delayed, rerouted, or cancelled.
This isn't a coincidence. Centinel's reconciliation system is designed around the same principles that corporate cash management teams have refined over decades. The core insight is the same: automated systems are excellent at handling routine, high-confidence cases, but ambiguous situations require human judgment. The optimal design isn't full automation (which would produce errors in ambiguous cases) or full manual review (which defeats the purpose of automation). It's a hybrid — automate the routine, surface the exceptions — that gives the user the benefits of both without the drawbacks of either.
Centinel's reconciliation system — the queue and the alerts together — is the mechanism that prevents silent forecast drift on the Premium tier. Without it, discrepancies between the forecast and reality would accumulate unnoticed. An auto-match that linked a transaction to the wrong event. A new recurring charge that was never added to the forecast. A cancelled subscription still being projected as a future expense. Each individual discrepancy might be small, but over weeks they compound undermining the reliability of the projections you rely on to (i) make spending and savings/investment decisions, and (ii) prevent overdrafts.
This is what makes Centinel's forecast a living system rather than a static projection. The matching algorithm handles the routine comparison between forecast and reality. The reconciliation queue and alerts handle the exceptions. And the feedback loop between them means the system learns your financial patterns over time, requiring progressively less manual attention while keeping the forecast's projections aligned with what's actually happening in your account.
STAY A STEP AHEAD
