Picture the last hour of the month. The bank statement is open in one tab, Shopify in another, and a spreadsheet between them. You are trying to make two numbers agree: what the store says you sold, and what the bank says you were paid. They never match. The bank shows a string of deposits, each an odd figure like 3,712.48, none of which is a day's sales, and Shopify shows a sales total that is bigger than all of them combined. Somewhere in the gap are the processing fees, the refunds you issued, a chargeback you half forgot about, and a reserve Shopify is holding. The job is to take each deposit, pull it apart, and prove it ties back to real orders. It is not hard arithmetic. It is the kind of slow, fiddly matching that eats an afternoon and gets done in a hurry, and a hurried reconciliation is how wrong numbers end up in the accounts you file taxes on.
This is one of the most common bookkeeping complaints in the ecommerce world, and it almost always sounds the same. A merchant looks at the money that hit the bank, sees it is smaller than their sales, and cannot work out why or how to record it without either double counting the revenue or losing track of the fees. The replies point at a Payouts page that lists totals but posts nothing, a CSV you sort out in a spreadsheet, an accounting connector that books the deposit wrong, or a paid app whose whole job is to summarize the payout for you. The merchant is not asking for anything exotic. They want the obvious thing every business needs: take the money that arrived, tell me which sales and fees it is made of, and put each piece in the right place in my books. The platform that ran every one of those sales hands that back to a human with a spreadsheet.
Shopify will tell you what you sold and tell you what it paid you. It just will not reconcile the difference between the two.
Why the deposit is never your sales number
Two mechanics make a Shopify payout impossible to eyeball, and they stack. The first is netting. The deposit is not your sales, it is your sales after Shopify subtracts everything that came out of them: the processing fee on every order, the full value of any refund you issued, any chargeback plus its fee, and any amount held back as a rolling reserve. So a week that sold four thousand dollars might deposit thirty-seven hundred, and the missing three hundred is not lost, it is fees and a refund and a hold, each of which belongs in a different place in your accounts. Record the deposit as a single lump of income and you have understated your real revenue, hidden your processing cost, and buried a refund, all in one entry.
The second is batching. Shopify pays on a rolling schedule, so a single deposit usually covers part of one day and part of the next rather than a clean calendar day, and one deposit can represent dozens or hundreds of individual orders and refunds rolled together. That is why no deposit ever equals a day's sales and why you cannot match by date. The deposit that landed Tuesday holds orders from Saturday afternoon through Monday morning, minus a refund from last week that finally cleared, minus the fees on all of it. Untangling which orders are inside which deposit is the actual work, and it is exactly the work the platform does not do for you.
What Shopify actually gives you, and where it stops
Shopify is happy to show you money moving. It just will not reconcile it. The gap shows up in three places merchants hit fast.
First, the Payouts page reports but does not post. Under Finances you get a list of payouts, and you can open one to see it broken into gross sales, fees, refunds, and the net that was paid. You can even export a payouts CSV or a transactions CSV. That is genuinely useful and it is also where the help ends. Nothing carries those figures into your accounting software as a real entry, nothing matches the net against the deposit in your bank feed, and nothing books the fee to an expense account and the collected tax to a liability account. You are handed the raw ingredients of a reconciliation and left to cook it yourself, every payout, every month.
Second, the accounting connector books it wrong. The official QuickBooks and Xero integrations sync order-level data, but they were not built to split a batched, netted payout into its parts and tie it to the bank. The result is one of two messes. Either the deposit gets recorded as fresh income when it lands, on top of the order revenue already booked, so the same sales are counted twice and the books overstate revenue. Or order income sits on one side and an unmatched bank deposit sits on the other, and the two never reconcile because the deposit is net of fees and refunds the connector did not account for. Both are the kind of error a bookkeeper finds at year end and has to unwind by hand.
Third, Flow cannot reconcile. Shopify Flow, free on every plan, can react when a payout is created and can send you a note that it landed. But Flow has no action that decomposes a payout, matches it to a bank deposit, or writes a journal entry, so it cannot book the sales, the fees, the refunds, and the tax to the right accounts. You can automate the alert that money arrived. You cannot automate the one step that matters, which is turning that money into a correct, matched entry in your books. That step still happens in a spreadsheet, in your accounting software by hand, or in a separate paid app.
Why the usual fixes don't hold
Once month-end starts to hurt, merchants reach for one of a few workarounds. Each one helps and each one breaks in a predictable spot.
"I will just click Add on the bank deposit." This is the single most common ecommerce bookkeeping mistake, and accounting forums and Reddit are full of people who made it. When the Shopify deposit shows up in the QuickBooks or Xero bank feed, clicking Add records it as a brand new income line in your checking account. But you already booked that revenue when the orders came in, so now the same sales are on the books twice, the fees are invisible, and the refunds inside the payout were never recorded. It feels like reconciling. It is quietly doubling your revenue.
"I will do it in a spreadsheet." This is the honest workaround, and it is the one that turns a founder into a part-time bookkeeper. You export the payout CSV, line up the orders, subtract the fees, account for the refunds and chargebacks, work out the collected tax, and write a journal entry, for every payout in the month. It works right up until the volume climbs or a busy week swallows the time, and it is fragile: one payout that spans a month boundary, one refund that cleared late, one reserve you forgot, and the spreadsheet stops tying out and you are hunting a few dollars at eleven at night.
"I run more than one gateway, so I do it twice." The moment a store takes PayPal or Shop Pay Installments alongside Shopify Payments, the problem multiplies rather than adds. Each gateway deposits on its own schedule, nets its own fees, and reports in its own format, and none of them line up with each other or with the orders. Now you are reconciling two or three separate streams of batched, netted deposits into one set of books, and a sale split across gateways, or a refund issued on one and not the other, is exactly where the numbers drift. The native tools treat each gateway as someone else's problem.
"I will let the connector handle it." The official sync is fine at copying orders. It is not built for the judgement reconciliation actually needs: knowing that a deposit is net of fees, that a refund inside it offsets revenue rather than creating an expense, that collected sales tax is a liability you owe and not income you earned, and that a deposit which does not match to the cent should be stopped and looked at, not forced to balance. A tool that books every deposit the same way will book the wrong ones the same way too.
What the automation actually has to do
The real job is not "import the deposit." It is "when a payout settles, take it apart into sales, fees, refunds, chargebacks, and tax, tie every piece back to the orders it came from, match the net to the exact amount that hit the bank, book each part to the right account, do it per gateway, and stop on anything that does not reconcile to the cent." That is decomposition, matching, and judgement, run across every deposit. As a Dugong playbook, in plain prose, it reads like this:
# trigger
On a payout settling, or a deposit landing in
the bank feed
# steps
1. Decompose the payout into gross sales, fees,
refunds, chargebacks, adjustments, and reserve
2. Match every line back to the orders and
refunds it came from
3. Tie the net to the exact amount that hit
the bank, to the cent
4. Categorize sales, fees, refunds, and
collected tax to the right accounts
5. Split each gateway on its own schedule and
its own fees
6. Hold any deposit that does not reconcile or
is missing an order for review
7. Post the matched entry and log which orders
rolled into itSeven lines. The compiler fills in everything underneath: reading the payout and the bank feed, resolving which orders and refunds are inside a batch that crosses a date boundary, separating the fee from the sale and the tax from both, recognizing a chargeback and its fee, keeping each gateway in its own lane, and posting a clean summarized entry that matches the deposit exactly while pulling the odd ones aside. The merchant never sat between a bank statement and a spreadsheet at month end chasing four dollars. They described how a careful bookkeeper would close the month, and let the compiler do the volume and catch the exceptions.
Why this is a compiler problem, not an app problem
There are capable reconciliation apps, and for a store with one gateway and a steady pattern they are a reasonable answer, which again proves the native gap is real. But the thing that makes payout reconciliation safe to automate is not pushing a summary into an accounting tool, it is the judgement around it: knowing a deposit is net of fees, that a refund offsets revenue rather than adding an expense, that collected tax is a liability and not income, that a batch crossing a month boundary has to be split across periods, and that a deposit which will not match to the cent should be held, not forced. Those are decisions about a particular set of books on a particular day, and the right answer shifts with every refund, chargeback, and reserve, which means a fixed rule was never going to hold.
A natural-language compiler fits because reconciliation was never really an import problem. It is a decomposition and matching problem wearing a bank deposit's clothes. Copying the number across is the easy part, which is why the connectors do it. The hard part is everything around it: split the deposit into its pieces, tie each to a real order, book it to the right account, keep each gateway honest, and bring a human in on anything that does not tie out. You can write that brief in a paragraph. You could never hold it across hundreds of orders and a dozen batched deposits a month by hand. It sits in the same family as the chargeback you lose by default, where the money leaves your account on a deadline you did not meet, and the return that won't approve itself, where every refund is a number that has to land in the right place before your books and your bank can agree.
The workflow worth building this week
If your bank deposits never match your sales, if you have ever clicked Add on a Shopify deposit and hoped, or if month-end close means an evening between a bank statement and a spreadsheet hunting a few dollars, this is the automation to set up before the next close lands, because every payout you reconcile by hand is time you will not get back and one misbooked deposit away from a revenue number you will pay tax on and a margin you cannot trust. It pairs naturally with the money work we have written about, like the chargeback you lose by default and the unpaid order that never cancels itself, and it feeds the same flywheel as the Shopify automations no one builds, where the work that compounds is the part merchants never get to.
Describe it the way you would brief a careful bookkeeper: when a payout settles, take it apart into sales, fees, refunds, and tax, match the net to what hit the bank, tie every line back to a real order, book each piece to the right account, do it for each gateway, and bring me anything that does not reconcile to the cent. That is the whole brief. The compiler does the decomposition, the matching, the categorizing, and the posting. You keep your evenings, and you stop being the slowest, most expensive step between a deposit and a set of books you can trust.
If you are a Shopify merchant who has wired up payout reconciliation that
ties to the cent instead of by spreadsheet, or you have a story about the
month you found a doubled deposit in your books at year end, the inbox is
open: field-notes@dugong.live. We are collecting case studies
for the next issue.