One shop, two sets of books. Every sale had to land in the right entity’s payment account and then match the right invoice, without someone sorting the money by hand each month.
One online shop taking money for two trading entities, with each order sent to the right payment account and matched to the right books.
Which entity takes the money is decided from what is in the basket, before payment is offered.
The accounting system already matches payments to invoices. The build feeds it rather than competing with it.
Most of the value in a system like this comes from the systems it talks to, and most of the risk does too. Each connection is scoped to the access it needs for the job.
The problems that decided how this was built. They are the reason it works the way it does rather than the obvious way.
The obvious answer to messy money is a custom matching system. It is also the part most likely to be wrong and hardest to audit.
Research into the bank and open-banking options showed the direct routes were closed or restricted, and the accounting system already did the matching. The build kept to routing and to the one gap it could not see.
Less code to trust, and reconciliation that an accountant can read in the tool they already use.
We don’t publish screenshots, logos or client names for this work. Much of it runs inside a business and handles sensitive data, so we describe what was built rather than who it was built for. We’re happy to walk through the detail on a call.
Every build on this page started as a workflow that off-the-shelf software nearly handled. Tell us where the gap is and we’ll scope what it takes to close it.