[benreesman]

I profoundly disagree that ML models are a good fit for transaction reconciliation.

It’s at least arguable that this task is the oldest documented use of writing, and from double-entry accounting to price/time precedence in modern market microstructure, we have algorithms that align very well with human intuition.

I can think of few cases where gratuitous application of even simple statistical methods would cause more harm than this one.

With all respect, the conversation becomes stupider with every post like this one.

[DecoPerson]

I have 15 debtors, a few dozen creditors, and 5 employee credit cards. There’s enough transactions that for the 3 years I’ve been reconciling the accounts I have wanted to either write an if/elseif/else-based reconciler assistant, or hire someone, or pay my accountant to do the job.

A few weeks ago, I decided, what the hell, and I spent two days writing a ChatGPT-powered reconciler assistant.

It’s so damn accurate. By feeding it relevant examples, it suggests the right journal entry for each bank transaction nearly every time, including saying “no matching entry” for when the corresponding journal entry hasn’t been posted yet.

It would have taken me a lot longer to write an if/elseif/else-based reconciler, and it have required a lot of manual attention… and the constant internal debate of whether the rules are code that should go in Git or data that should go in the DB.

I think ML models are a great fit for transaction reconciliation because they give good-enough results really fast at a reasonable price. I’d prefer that over continuing to spend my own time, or having to learn the more advanced algorithms you mentioned.

Something is better than nothing.

[thfuran]

Whether something is better than nothing depends on its error rate and the consequences of an error.

[lazide]

And the awareness that nothing is perfect, including manual reconciliation.

[snapcaster]

Fair, but also humans working manually don't have a 0% error rate

[bsder]

I thought the whole point of double entry bookkeeping is to make sure that the error rate is, in fact, precisely 0% and verifiably so.

[lmz]

You can still reconcile the wrong things and have the books balance. e.g. you sell a subscription for $1. User A paid on the 1st, user B paid on the 3rd. You mistakenly reconcile user A's payment to user B's bill and vice versa. Your books still balance, but you better hope you didn't charge user A any late fees.

[withinboredom]

Right. Like now I'm wondering if I should edit my statement description in Stripe to be adversarial to AI reconcilers; just for giggles.

[benreesman]

The precision/recall behavior of LLMs tends to get glossed over.

You’re quite right.

[daft_pink]

I wrote one using fuzzy logic once that was super successful as well years ago, but it wasn't something I would use on audited transactions.

[bradteamworks]

Would you be willing to share your approach? I'd love to see it. Disclosure: I'm in the early stages of an open-source ERP: https://github.com/barbinbrad/carbon