A Shopify deposit is one order and two charges. Your books have to see both.

What lands in your records, twice

Take a $2,000 made-to-order piece with a 30% deposit. The customer pays $600 in March; the balance of $1,400 is charged in June. Here is what each moment puts where.

The important line in that pair is the one about the order total. Paying a deposit does not make the order a $600 order. Shopify tracks the shortfall in a separate field — totalOutstandingSet, documented as “the total amount not yet transacted for the order” — and leaves the order value alone.

The consequence is the one that catches people out at month end, and it is inference from those field definitions rather than something Shopify spells out: any report built on orders and any report built on cash will disagree while a balance is outstanding, and the gap is exactly the sum of the outstanding balances. That is not a bug in anything. It is what a partly paid order is.

Sources for this section: the payout breakdown of “charges, refunds, adjustments, and reserves”, the per-transaction detail and the transactions CSV columns (Transaction Date, Type, Order, Card Brand, Card Source, Payout Status, Payout Date, Available On, Amount, Fee, Net) are from help.shopify.com’s payout-details page. The order-export columns, including Financial Status, Paid at, Taxes, Total and Outstanding Balance, are from its export-orders page. I have seen it reported that Outstanding Balance appears only when the POS sales channel is installed and could not confirm that either way, so check your own export before you build a process on that column. The same-order behaviour is from the Admin API: orderCreateMandatePayment takes “the ID of the order to collect the balance for”.

One order or two

This is the question worth asking before you install anything, because the answer is not the same for every app and it is the difference between a tidy ledger and a manual reconciliation every month.

The complaint that started this page was put more precisely by a merchant than by any vendor:

“Depo is the closest and it ends up creating multiple orders to cover the partial payments, which is going to be an accounting nightmare.”

For the record, the same merchant did not leave Shopify over it. They said they would keep using Square Invoices for that one part of the business while everything else stayed on Shopify, which is a smaller and more believable outcome than the version that gets repeated.

Three mechanisms, three ledgers

• Deferred purchase options — one order. The deposit and the balance are two charges against a single order. This is Shopify’s own mechanism, the one the balance-charge mutation is built around, and the only one where the two halves are joined by the platform rather than by you.
• A deposit sold as its own product — two orders. Cheap, works today, no app needed, and nothing links the deposit order to the balance order. Your books see two sales of two different things, and the deposit product distorts your product reporting as well.
• A second checkout or an emailed invoice — two records, in two systems. Whether that is a draft order, an invoice tool or Square, reconciliation is a human joining two identifiers by hand.

Worth knowing that the most established deposit app in the category documents the problem itself, on its own help site, which is more honest than the marketing pages around it:

“Since Downpay does not collect the entire order amount at checkout, this assumption no longer holds. While some accounting software will properly account for multiple payments on the same order, many others do not.”

That is the right diagnosis. The problem is rarely Shopify’s order record. It is the assumption downstream that an order’s total equals the cash it brought in.

QuickBooks, Xero and A2X

In practical terms, whether deposits reconcile depends on one thing about your accounting integration: does it post from your payouts or from your orders?

Payout-based tools cope

A settlement-based tool summarises what actually hit the bank. A2X describes its own model as posting one journal per payout: “A2X focuses on payout-level reconciliation. It summarizes your Shopify transaction data and sends one journal entry per payout to QuickBooks Online, ready to match against the bank deposit.”

Read that against the two-payout picture above and the deposit problem largely dissolves. The $600 is in the March journal, the $1,400 is in the June journal, each ties to a real bank deposit, and neither pretends the order was settled in one go. Cash reconciliation is not where deposits hurt.

A2X’s documentation says nothing specific about consumer deposits or pre-orders that I could find — the nearest thing is its B2B article, which notes that “partial payments won’t sync back to Shopify” in that different context. Treat the deposit case as undocumented rather than endorsed, and test it on one order.

Order-based syncs are where it breaks

A sync that creates an invoice or a sales receipt per Shopify order has to decide what a $2,000 order with $600 collected means. Some handle it as an invoice with a part payment applied. Others book $2,000 of income and leave you a $1,400 discrepancy against the bank until June, which is precisely the case Downpay warns about above.

I could not verify what Shopify’s own QuickBooks connector or Xero’s Shopify app do with a partly paid order — I found no statement either way in their documentation, and their sites did not respond to repeated attempts to read the relevant pages. Treat that as unverified rather than as a no.

What to actually do

• →Reconcile cash from payouts, not orders, for any period with balances outstanding. Two settlements against one order is normal and the payout record already says so.
• →Keep the outstanding balances as their own figure. They are the reconciling item between order-based and cash-based reports, and having the number to hand converts an argument into a line.
• →Run one real order through the whole cycle before you run a hundred: deposit, wait, balance, and look at what appeared in your accounting system at each end. This is twenty minutes that saves a quarter-end.
• →Ask an app vendor the one-order question in writing. “Does the balance charge land on the original order, or create a new one?” The answer determines everything above.

Revenue or liability

Shopify documents nothing about this. Not on its deferred purchase options page, not on its pre-orders setup page, not on its deferred-payments or partial-payments pages. There is a general explainer about deferred revenue on Shopify’s blog which never mentions the deposit feature. So the platform is not going to tell you how to book it.

The concept most bookkeepers reach for first is that money received before you have delivered is not yet yours. QuickBooks’ own help article puts it plainly:

“The retainer or deposit is treated as a liability to show that, although your business is holding the money from a deposit or retainer, it doesn’t belong to you until it’s used to pay for services.”

Under IFRS 15 the same idea has a name — a contract liability, defined as an entity’s obligation to transfer goods or services to a customer for which the entity has already received consideration. ASC 606 uses the same model in the United States. Xero has a comparable help article on recording prepayments. None of that is a ruling on your situation; it is the vocabulary.

The questions that actually decide it

• Is the deposit refundable? A fully refundable deposit and a non-refundable one you keep if the customer walks away are not the same thing, and a refundable security deposit is treated differently again from a part-payment towards a price.
• When is your performance obligation satisfied? Order, manufacture, dispatch, delivery, installation, completion. The date you deliver is the date the liability turns into revenue, and for made-to-order work it is often much later than the deposit.
• Cash basis or accrual? A small business on a cash basis may have a materially simpler answer than one reporting under IFRS or US GAAP.
• Which jurisdiction, and which reporting framework? This is the question that makes any single answer on a web page wrong for most readers.
• Does your Shopify reporting help or hinder? Shopify books the order at its full value on the order date. If your accountant wants the deposit held as a liability until delivery, that mapping is manual, and it is worth agreeing how before the first order rather than after the fortieth.

Tax on the deposit versus the balance

I am not going to guess at it, because a guess here becomes somebody’s VAT return. What I can tell you is where the pressure lands.

The order carries a single tax total for the whole order from the moment it is created, on one order date. Tax authorities do not necessarily agree that this is the date that matters. HMRC’s VAT time-of-supply manual states that “a pre-payment or deposit intended by the payer and recipient to eventually form part of the consideration for an identifiable supply, will create a tax point” — and it carves out security deposits, which are treated differently, in a separate section. That is a tax authority on VAT, in one country. It is not Shopify on Shopify, and it does not transfer to other jurisdictions.

So the practical position is this. If your tax point is the deposit date and Shopify shows one tax figure against one order date, those two facts have to be reconciled by hand, and which date governs is a question for your accountant and your tax authority rather than for your app vendor. A rate change between the deposit and the balance is the case with no published answer at all — I do not know how Shopify behaves, and I have not found anyone who has documented it. If you are on a long lead time through a rate change, raise it with your accountant early.

What the fees actually do

“You pay the fees twice” is the usual claim, and it is half right in a way that matters to the arithmetic.

Start with what Shopify states outright, on its page about capturing payments: the transaction fees apply to each capture. A deposit and a later balance are two captures. So the fee is incurred twice.

But percentage fees add up. Two captures of $600 and $1,400 carry the same percentage total as one capture of $2,000, because the pieces sum to the whole. What genuinely doubles is any fixed per-transaction component of your gateway’s rate — the “plus 30 cents” part. That is one extra fixed fee per deposit order, not a doubling of your processing cost.

The third-party fee, precisely

Shopify charges a third-party transaction fee when you process through a gateway other than Shopify Payments, and it states that “if you use Shopify Payments alongside a third-party payment provider, then transaction fees apply”. Two details are worth having exactly right, because they change which of the four deposit-capable gateways costs you extra:

• PayPal Express Checkout is on Shopify’s exempt list. With Shopify Payments active, Shopify names Shopify Payments, Shop Pay, Shop Pay Installments, PayPal Express Checkout and manual methods as not attracting third-party fees. So a PayPal Express deposit does not, while Stripe and Adyen do.
• Store credit and gift-card portions attract fees even with Shopify Payments active, per Shopify’s own worked example on that page.
• Shopify’s third-party fee is a flat percentage with no fixed component, so splitting a payment does not increase it. The fixed-fee doubling comes from your gateway’s rate card, not from Shopify’s.

The honest summary: a deposit order costs you one additional fixed-fee component and one additional line in your fee reporting. It does not cost you double. Anyone telling you otherwise has not done the arithmetic.

Two things you cannot undo

Both of these are operational rather than accounting, and both end up in the books, so they belong here.

You cannot refund the deposit alone

The clearest published statement comes from a deposit app’s own documentation rather than from Shopify: “Currently Shopify cannot refund just a deposit or just a future payment.” I could not find a first-party Shopify sentence on it, and I checked its deferred-payments and Shopify Payments refunds pages.

In practice that means returning a deposit is a refund against the order, handled like any other refund, and the deposit-versus-balance distinction your customer cares about is not one the refund mechanism understands. Whether processing fees come back on a refunded deposit is a further question Shopify does not document clearly, and I am not going to assert an answer.

Cancelling the order removes the card

From the same source: “Cancellations will remove the card on file for a given order to prevent accidental charges.” That is sensible behaviour and it is also a one-way door. There is no cancel-then-reinstate path back to collecting a balance, because there is no way to re-vault the card against that order.

So: never cancel an order you still intend to collect on. If a customer wants to pause rather than cancel, that is a conversation, not a cancellation. And if a card expires before a long-dated balance falls due, the fix runs through a payment-method update link — which expires 48 hours after it is sent, so it is worth knowing that a customer who reads their email on Monday has already missed a link sent on Friday.

Before you install anything

• →Does the balance charge land on the original order, or create a new one? Get it in writing.
• →Does your accounting integration post from payouts or from orders?
• →Ask your accountant now whether the deposit is held as a liability, and on what date it becomes revenue.
• →Ask your accountant which date is your tax point for a deposit, and how to reconcile it with an order-dated tax figure.
• →Look up the fixed per-transaction component of your gateway rate and multiply it by your expected deposit orders. That is the real fee difference.
• →Run one order all the way through — deposit, wait, balance — and read your own payouts, exports and ledger at both ends.

Where my own app fits

I build one of these, so read the page with that in mind. It is most of why the fee arithmetic above argues against the more flattering version.

Questions

Related

If you are an accountant and something here is loosely put, I would genuinely rather be corrected than quoted — support@depositdesk.app. Everything was checked against first-party documentation on 11 August 2026, and none of it is accounting or tax advice.