Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reconciliation is a knapsack problem

moderntreasury.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Reconciliation is a knapsack problem

#51

Post by benreesman »

thfuran wrote: post #16
DecoPerson wrote: post #14

Earlier quoted context omitted.

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. B…

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

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

You’re quite right.

Re: Reconciliation is a knapsack problem

#53

Post by rowyourboat »

mattkrause wrote: post #42
Semitangent wrote: post #36

Can someone help me understand the premise of this article? I think the goal here is to map the internal books of a business to their bank account, but I have never seen the kind of "grouping" the article seems to assume as given. In which scenarios do these groupings happen? If there are several customers, there will be different invoices and therefore separate payments. Why would the bank just throw them together,…

A mundane example is iTunes purchases. If you buy something for $0.99 today, they won't bill you immediately. If you buy another $0.99 item tomorrow, you'll get a consolidated charge for $1.98. You would need to do something like this to link the $1.98 to your app/song purchases. The reason for this is that credit card processing often costs a flat service charge + a percentage of the bill: Stripe is 30 cents + 2.9%…

But even then, Apple knows exactly which purchases it consolidated into which payment, making the entire process trivial again

Re: Reconciliation is a knapsack problem

#54

Post by xtiansimon »

mattkrause wrote: post #42
Semitangent wrote: post #36

Can someone help me understand the premise of this article? I think the goal here is to map the internal books of a business to their bank account, but I have never seen the kind of "grouping" the article seems to assume as given. In which scenarios do these groupings happen? If there are several customers, there will be different invoices and therefore separate payments. Why would the bank just throw them together,…

A mundane example is iTunes purchases. If you buy something for $0.99 today, they won't bill you immediately. If you buy another $0.99 item tomorrow, you'll get a consolidated charge for $1.98. You would need to do something like this to link the $1.98 to your app/song purchases. The reason for this is that credit card processing often costs a flat service charge + a percentage of the bill: Stripe is 30 cents + 2.9%…

That’s how it happens, and let me add the problem occurs _between systems_.

In this example we have Apple’s charge (receipts) and the consumer’s bank withdrawals (statements). This example gives you an idea of a consumer’s purchases, which are simple to reconcile.

The post is about the Business to Business situation, which deals with greater volume and therefore more complex problems. The OP uses a toy example. If you’ve done financial reconciliation, then you will recognize the problem behind the trivial example.

Re: Reconciliation is a knapsack problem

#55

Post by twic »

whatever1 wrote: post #4

lol at ai for solving deterministic knapsacks. Just get yourself a solver. And if you wanna solve billion item sized problems hire an OR scientist to write a decomposed algo. Literally after 2 minutes of search: https://arxiv.org/pdf/2002.00352.pdf

What does this have to do with the article?

Re: Reconciliation is a knapsack problem

#56

Post by shaftway »

rowyourboat wrote: post #26

I don't understand the problem this solves. At least in my experience each transaction on the bank statement has a reference to a business transaction attached (usually an invoice number). The amount of money that just lands on the account without a reference is negligible in comparison and usually easily manually associated.

Often banks will batch up transactions into a single one, and especially in a real-time market, that may not match what you expect.

For example lets say I ask you to sell 10 shares of Google if the price goes over $140 (this is typically called a limit order). Now your bank comes back and says the sold 2 shares at $140.02, 7 shares at $140.03, and 1 share at $139.77. Did they satisfy their obligation?

The answer is yes, but it's difficult to determine that, and you can't use exact math to do it easily. You expected $1400 from that sale, but you got $1400.02. Now do it again, but you have half a dozen orders at different prices. That's where it turns into the knapsack problem.

The problem is severely compounded when you look at why you're reconciling (it's to make sure your assets changed the way you expected, and fix things when it didn't). Often banks will drop a transaction, or add an extra one (these systems are annoyingly manual, and subject to error). How do you find the exact error and track it down? Especially when the trade happened, but you don't have the actual record of it, and your records show that it didn't.

Re: Reconciliation is a knapsack problem

#57

Post by dreamcompiler »

rowyourboat wrote: post #53
mattkrause wrote: post #42

Earlier quoted context omitted.

A mundane example is iTunes purchases. If you buy something for $0.99 today, they won't bill you immediately. If you buy another $0.99 item tomorrow, you'll get a consolidated charge for $1.98. You would need to do something like this to link the $1.98 to your app/song purchases. The reason for this is that credit card processing often costs a flat service charge + a percentage of the bill: Stripe is 30 cents + 2.9%…

But even then, Apple knows exactly which purchases it consolidated into which payment, making the entire process trivial again

Yes but you don't have access to Apple's database, and therein lies the problem. Apple might send you a receipt that itemizes these things, or it might not. If you're a business you're dealing with 1000 different Apples all of whom have different policies about how granular their receipts will be, each with a different mechanism for you to access those receipts, and each making receipts available at different times.

Meanwhile you need to do a reconciliation for your company at the end of every period (e.g. the end of every day, every week, etc.) and you don't have time to wait around for all those receipts to be collected.

Post reply on HN