Reconciliation is a knapsack problem

As somebody who worked as an accountant, I saw several times where automated reconciliation solutions devastated books with repeat mistakes and lacking audit logs. I saw interns do the same, too.<p>An automated solution to reconcile statements based on LLM matches removes transparency on how your books are prepared and might create a false sense of trust in the preparation of your books. In case of an audit, people will be in great trouble when their answer is ‘yeah, the AI booked everything.’<p>I think there is an opportunity here, but I don’t see it ending well until we can put the accountability of your accounts in check.

I&#x27;m head of processing development at PayProp[^1] where we&#x27;ve been automatically reconciling rental payments for two decades using the techniques described in the article - we just don&#x27;t call it an AI or a LLM. Our tech saves letting agents huge amounts of time.<p>We look at the data we have and if it&#x27;s sufficient we can &quot;automatically&quot; reconcile it - i.e. suggest a match with 100% certainty that the user(s) can then confirm. Otherwise we make an informed suggestions based on all of the likely data from the transaction(s) and sometimes the suggestions are a list of possible matches.<p>IME the biggest problems in recon are the edge cases around failures in the banking system or the flow that are very difficult to code around and require manual intervention:<p>* failures of payments X days after they have been reconciled, now you have to pull things apart again * bank reverses transactions but then puts them back and this appears in their intra day statements (MT942 files for example) but doesn&#x27;t show on their online portals, leading to &quot;duplicates&quot; in one system that aren&#x27;t really * statement and reference data is incomplete or just wrong (who knew that free text fields can be problematic?) * amounts simply don&#x27;t match because you invoiced for X and were paid Y - payments are split up to get around constraints, amounts are rounded up, etc.<p>We deal with these every single day, and we are automating what we can - but you&#x27;re always going to need a human to confirm the final step in these cases. Perhaps an LLM can improve suggestions, but when the data is just wrong or missing then I&#x27;m not so sure.<p>[^1]: <a href="https:&#x2F;&#x2F;us.payprop.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;us.payprop.com&#x2F;</a>

I profoundly disagree that ML models are a good fit for transaction reconciliation.<p>It’s at least arguable that this task is the oldest documented use of writing, and from double-entry accounting to price&#x2F;time precedence in modern market microstructure, we have algorithms that align very well with human intuition.<p>I can think of few cases where gratuitous application of even simple statistical methods would cause more harm than this one.<p>With all respect, the conversation becomes stupider with every post like this one.

This brings me right back to June of 2009, as the markets started to spoil and the derivative markets fells to shambles. A few hapless souls in Baltimore would be tasked with manning 2 standing 12 hour shifts for as many weeks as it would take to properly reconcile what could only be described as a tsunami of unreconciled data for a single large custody player in the sub-prime markets. It took about 4 months, and went through several phases of rebalance but we got it done. As I look across the landscape of LLM, the word &quot;context&quot; screams back at me. I think the processing power involved to make all the poor choices necessary to find the right choices and wonder how that could&#x27;ve been done without a teams of people thinking about the same problem from many perspectives.

lol at ai for solving deterministic knapsacks.<p>Just get yourself a solver.<p>And if you wanna solve billion item sized problems hire an OR scientist to write a decomposed algo.<p>Literally after 2 minutes of search: <a href="https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2002.00352.pdf" rel="nofollow noreferrer">https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;2002.00352.pdf</a>

I don&#x27;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.

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 &quot;grouping&quot; 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, thereby creating the problem this article is trying to solve? I&#x27;m asking from Germany, in case this is one of these Europe-US kinds of differences.

<a href="https:&#x2F;&#x2F;github.com&#x2F;Gnucash&#x2F;gnucash&#x2F;blob&#x2F;stable&#x2F;gnucash&#x2F;gnome-utils&#x2F;gnc-autoclear.c">https:&#x2F;&#x2F;github.com&#x2F;Gnucash&#x2F;gnucash&#x2F;blob&#x2F;stable&#x2F;gnucash&#x2F;gnome...</a><p>This is something I&#x27;m familiar with! I refined the above algorithm to reconcile statements according to the statement end balance. It works well, and yes it&#x27;s knapsack.

Are these people selling software to order transactions for maximum fines?

I&#x27;ve written code for some reconciliation systems and it&#x27;s nice to have confirmation they are indeed hard nuts to crack. The language matching isn&#x27;t really the hard part IMO. What&#x27;s tricky is that you&#x27;re often matching batches &quot;up to N&quot;, and the matching is not always just on a equal values or dates. For example, 300 credit card swipes at point of sale might match 3 deposits in the bank account a few days later with a 3% fee deducted. They never clear on the _same_ day, but need to match nearest day first. To brute-force, you need test all batches of up to 300 point of sale transactions and all batches of up to 3 deposits.

Maybe I&#x27;m misunderstanding the problem but you don&#x27;t match payments to transactions. You would have a ledger that debits transaction and credits payment resulting in a current balance.<p>The reconciliation system that I work on tries to match data from different system to make sure they agree. Like match the Visa transaction file against what our system has internally recorded in its ledger. There is an unique key to match both records so no math involved.

Can anyone recommend a reconciliation application they&#x27;ve had a good experience with? My current work place rolled their own recon service. Is this the norm?

I was thinking that they were talking about netting&#x2F;clearing and how to minize the amount of transactions that need to happen as actual wire transfers.<p>Actually no. This post is about doing something akin to first in first out accounting to match the payments to the invoices.<p>I wonder why they aren&#x27;t simply using virtual IBANs...

Well, Reconciliation is certainly not a Knapsack problem, but I couldn&#x27;t get over how most video game RPGs, e.g. Skyrim, are ultimately making a lot of fun out of the Knapsack problem.<p>I really want an automatic inventory pickup system based on it

Even better is no reconciliation at all. Just keep all the data where it belongs so you don&#x27;t have to reconstruct the data and inevitably make up data.

This makes me think of that passage in Cryptonomicon where an estate being divided among relatives was likened to the Knapsack Problem.

I think they got their math wrong too: the binomial coefficient for (5 1) is 5, not 120.

This feels like a marketing piece without any good content.<p>The way it&#x27;s described, it&#x27;s not a knapsack problem at all. The knapsack problem is to maximize the total value of the items you fit into the container.<p>In reconciliation, you presumably want to get the best matching between transactions, which is not defined here, and in any case is a completely different problem.<p>Ignoring the knapsack comparison, the article doesn&#x27;t describe why you&#x27;d want to check each possible combination. Assuming the individual amounts are correct, you can do each batch separately - no need to check each combination within one batch with each combination of a different batch. (And if you drop that assumption, that still won&#x27;t be a sensible thing to do).<p>I can imagine you can have a &quot;scoring&quot; algorithm that gives a confidence score for a match - then if you check every combination, you can pick the combination with the best overall score. But the article doesn&#x27;t actually describe anything like that.<p>It also doesn&#x27;t describe any alternatives to &quot;AI&quot;. For example, what about a greedy algorithm? What about alternative methods to do address comparisons? I&#x27;m sure there are issues with those, but none of that is described here.