Is typing in your spending more accurate than a bank feed?

One week, two records

Here is a made-up but realistic week in Sydney. The left column is what a bank feed would show, in the shape feeds use: raw merchant strings, one row per card event. The right column is what a person typing it in on the day might write.

Now add them up. What this person actually spent on their own life that week was A$224.88: the coffee, A$68.40 of groceries, the A$18 gift, A$27 of cash spending, the phone case, the parking, their A$52.80 half of dinner, and Spotify.

• The feed, as it lands on Saturday morning, says A$396.68. The pending dinner and the posted dinner are both there, and the pending amount is wrong because the tip went on after the card was first authorised.
• The feed, once the pending row drops off, says A$300.68. Still A$75.80 too high: it counts the whole A$50 withdrawal although A$23 of it is still in a wallet, and it counts the whole dinner although half of it came back on Sunday, where it will likely look like income.
• The hand-typed record says A$220.68. A$4.20 too low, because the parking did not get entered.

So neither is "accurate" out of the box. The feed is off by A$75.80 until someone tidies it; the hand record is off by A$4.20 until someone notices the gap.

What each got right

Why feeds look like this

None of this is a fault in any particular app. It is how card data arrives, and the feed providers say so plainly in their own help pages.

• Pending and posted are separate events. Plaid, the connector behind many apps, says that if a transaction "is updated, modified, or posted, it will appear as a separate transaction", so the app has to match the pair itself. PocketSmith says its duplicate check most often misses when the two copies have different dates, which "usually affects pending transactions", or different merchant names, which "are often updated after the pending transaction becomes posted".
• The amount can change. YNAB's help on pending transactions warns that "by the time the transaction clears, the bank can update the amount, payee, or even remove the transaction altogether".
• Merchant details are a best guess. Plaid again: "information about a merchant, such as its name or category, may be incorrect."
• Connections need upkeep. Monarch explains that some institutions give apps access "only for a limited time", after which you reauthorise through the bank's login, and that this "happens regularly with certain banks".

Every app works hard to smooth these over, and most of the time it does. But the upshot is that a feed gives you a complete list of card events, and turning that into "what I spent, on what" is still a job for a person.

The case for the moment of typing

There is also an argument that typing it in changes what you notice, not only what you record. In two experiments, the consumer researcher Dilip Soman found that past payments reduced people's intention to spend more strongly when the payment method made them write down the amount paid, which he called rehearsal, and when the money left their account straight away rather than later. That is a lab finding about purchase intention, not proof that any tracker changes behaviour.

When a bank feed is the better fit

If you have several accounts and cards, pay mostly by card, and mainly want a complete list without the daily habit, a feed is a sound choice. The same goes if you are reconstructing a year for tax, or if you know you will not keep up with typing. Many people do well with a feed plus a weekly ten-minute review of new rows: that review is where the categories, splits and repayments get fixed.

Hand entry suits people who want each row to mean something on the day, who use cash or share costs a lot, or who would rather not give an app a bank login. Its weak spot is the forgotten purchase, and the fix is a regular catch-up: compare a week of your statement against what you typed, and add what is missing. In the example above, that would have taken one line.

Questions