Most personal finance apps put bank syncing at the center. You connect your accounts, wait for transactions to arrive, categorize them, and move on. It’s a useful model, but it rests on an assumption: that the bank feed is the primary record of your financial life.

Carlo starts somewhere else. The important act isn’t importing a transaction from your bank. It’s remembering the transaction happened at all. That sounds like a small distinction, but it changes how bank sync should work.

Manual first, bank second

Carlo is built around manual entry because logging money by hand creates awareness. The few seconds it takes to record the coffee, the grocery run, or the dinner that ran long are part of the practice. A fully automated feed is excellent at building a ledger, but automation can also make money easier to ignore: a transaction appears, gets categorized, and disappears into the record without ever passing through your attention.

Carlo doesn’t want bank sync to replace that moment. It wants bank sync to answer a narrower question: did I forget anything? The bank becomes a second set of eyes.

The bank feed is useful, not perfect

Bank data is valuable, but anyone who has worked with it knows it’s messy. Transactions arrive late. Pending charges change when they post. A restaurant reports the pre-tip amount, then revises it. Merchant names come through abbreviated or wrapped in processor codes, so a charge you remember by the name over the door may not look like one. A utility bill can swing month to month. And sometimes you just don’t know what a charge is yet.

Peer-to-peer payments are the clearest case of what a feed can’t see. Pay a friend through Venmo or Cash App from your linked bank account and it often lands in the feed as a single transfer to “Venmo,” with none of the detail about who you paid or what for. Fund the same payment from an in-app balance and it may never reach your bank at all, so the feed never shows it. The record of what actually happened lives inside the payment app, not the bank. If you want that spending to count, you have to remember it yourself.

Traditional bank-feed products handle the general mess well for the problem they’re solving: getting transactions into a ledger and helping you review them. Carlo is solving a different problem. If you already logged something manually, the question isn’t “what transaction is this?” but “does this bank activity match something I already remember entering?” That takes a different workflow.

An inbox, not a calendar

Our first version of Bank Reminders attached bank activity to individual days. Conceptually it made sense: the transaction happened Tuesday, so show it on Tuesday. In practice, bank data doesn’t cooperate. A Tuesday purchase might not post until Thursday. A pending transaction can change after you’ve reviewed it. The bank’s date and the date you logged something often differ.

That turns reconciliation into navigation: back to yesterday, then the day before, comparing amounts, trying to remember where you entered something. It’s too much friction for a feature meant to reduce uncertainty.

So Bank Reminders is becoming one dedicated place to review unresolved activity, closer to an inbox for financial loose ends. Three states are enough: To Review for activity Carlo hasn’t resolved, Later for things you don’t understand yet or don’t want to deal with now, and Resolved for anything you’ve matched, logged, connected to a bill, or intentionally ignored. A transaction arriving a day late is no longer a navigation problem. It just appears in the queue, and you deal with it when you’re ready.

Matching without overclaiming

Carlo already tries to match bank activity to what you recorded manually, and the rules are deliberately conservative: strong merchant-and-amount matches first, then exact amounts on the same day, then exact amounts within a small date window, then unpaid bill occurrences. Underneath all of it sits one principle: if Carlo isn’t confident, it should ask rather than guess. A wrong match is worse than no match.

But exact matching has blind spots. Suppose the bank shows Laundry for $54.02 and you logged Laundry for $59.02 — maybe you added a $5 tip the authorization hasn’t caught up to. An exact-amount algorithm calls these unrelated. A person looks and says they’re obviously the same thing. So Carlo needs two ideas: an exact match, where the evidence is strong, and a possible match, where the merchant, timing, and context line up but something differs. A possible match never resolves silently. Carlo surfaces the difference (amounts differ by $5.00, bank $54.02, logged $59.02) and lets you decide: match anyway, update the logged amount, keep separate, or deal with it later. That’s more useful than pretending imperfect data is precise.

“I don’t know yet” is a valid answer

A lot of financial software quietly assumes every transaction should be understood the moment it arrives. Real life doesn’t work that way. Sometimes the merchant name is useless, sometimes you’re waiting on a pending charge, sometimes you need to ask your partner, and sometimes you just don’t want to think about it. Later should be a real answer, not a warning or a failure to finish your homework. Every unresolved item doesn’t need to feel like a problem demanding attention. A good reconciliation system should reduce that pressure, not add to it.

Bills belong in the same place

Bank activity can also help keep recurring obligations organized. If the bank reports a utility bill for $188.24 and you already track that bill, a big swing from last month shouldn’t disqualify the match. A bill isn’t an exact fingerprint; it’s an obligation that varies. So bill matching leans on payee identity, timing, and whether the bill is already paid, rather than the amount. And when no bill exists, Carlo can offer to set one up without overclaiming. There’s a real difference between “this definitely looks recurring” and “would you like to track this as a bill?” The second is useful well before Carlo has the history to make the first claim responsibly.

How this differs from YNAB, Monarch, and Copilot

All three have thoughtful bank-sync workflows built on slightly different philosophies. YNAB is closest to Carlo in spirit, with strong support for reviewing imported transactions and matching them against manual entries. Monarch emphasizes a polished synced ledger with review states and automation. Copilot leans into a highly automated feed with categorization and recurring detection. These are all sensible, but they generally treat imported bank data as the primary stream you manage.

Carlo’s model is manual-first. You record what you remember, and the bank arrives afterward as corroboration. That leads to a different question: does what the bank saw line up with what I thought happened? The difference is subtle but real. Carlo isn’t trying to build the fastest bank-fed ledger. It’s trying to make manual awareness reliable.

The goal isn’t zero effort

Personal finance software often competes on how much work it eliminates, and sometimes that’s right. But not every bit of friction is bad. Logging a purchase by hand takes a few seconds, and those seconds create awareness a feed can’t. Bank Reminders isn’t meant to remove that practice, only to make it dependable without making it tedious.

You remember what you can. Carlo remembers what you told it. The bank catches what slipped through. When the three don’t quite agree, Carlo gives you one calm place to sort it out.

If you want the background on how Carlo connects to a bank in the first place, and the tradeoff between the two providers, I wrote about that here.