Deposits, part-payments and the balance, tracked to the cent

An illustrative spreadsheet row reads: “Sofa: $2,400 card, $500 check?, balance $1,900 or $2,400?” The associate remembers the check. The register doesn't. Delivery is booked, and the customer thinks the matter is settled.

Keep every completed payment on the order and separate it from an unpaid request. OrderPilot's Payments panel gives the team a shared Paid amount and Balance, with the history behind them. The goal is simple: the associate, bookkeeper, and person arranging delivery should be reading the same answer.

Give the balance one owner and one record

Balances drift when money arrives through different channels and the order changes between collections. The link was paid at home; the check went to the office; a designer arranged a wire; somebody added the matching ottoman. None of those events should require a second ledger with its own version of the sale.

Assign responsibility for matching outside receipts to orders. The person may be in the back office, but the habit belongs to the whole team: identify the order, confirm the money received, record it through the supported method, and leave enough reference for another colleague to reconcile it.

A promised wire is not a received payment. A payment request is not a receipt. A screenshot from the customer can help locate a transfer, but the store still needs to establish what actually arrived.

The deposit guide covers the first collection. This routine carries the same record through each later payment.

Read the payment history before asking for more

The Payments panel shows the financial events behind Paid and Balance. Deposit orders, recorded payments, and store-credit use should be recognizable as distinct entries, with their amounts and status.

The balance relates to the order total, including the charges and tax calculated for that order. When tax, delivery, quantity, or price changes, use the updated total rather than subtracting payments from an old quote PDF. The customer should hear the current amount and the reason it differs.

Payment collection also differs by plan and order stage. Shopify's March 26, 2024 announcement describes native partial payments on orders with payment terms. In OrderPilot, partial manual payments on a placed order need Shopify Plus. Admin deposit orders are the any-plan route before placement when enabled.

Use the plan-by-plan comparison to establish the store's route before offering a payment schedule.

Request a clear amount for a clear reason

Tell the customer what the request covers and what remains afterward. “Payment due” is less useful than “the agreed second payment before the sofa leaves our warehouse,” accompanied by the current amount.

OrderPilot supports percentage and amount choices in its supported collection flows. For example, an associate might select 25% or enter an agreed amount directly. Read the resulting currency amount before sending, especially where earlier payments or an order change have altered the balance.

A request cannot exceed the amount available to collect. Outstanding payable requests matter because the customer may still pay one after the office has received money another way. That is why a request needs its own lifecycle: issued, paid, or canceled.

Resolve an old request before changing the collection plan

An open deposit request must be paid or canceled before another deposit order is requested. More generally, OrderPilot accounts for money already requested on still-payable invoices when limiting additional collection. Multiple historical entries in the panel do not mean that every link should remain active.

Suppose an illustrative $800 request is open and the customer instead brings a check for that amount. Reconcile the old request first, then record the check through the supported flow. Do not leave the payable link in the customer's inbox and independently mark the full order paid.

OrderPilot blocks Mark as paid while conflicting payable requests remain open and caps other recorded amounts against uncommitted balance. If the screen refuses an amount, read the outstanding requests before trying another method. The refusal is often pointing to a payment someone can still make.

Follow a changed order through the arithmetic

Use a single worked example to see why the original deposit percentage isn't enough. Say a sofa and chair total $5,200, with tax and fees already included for this example. The customer pays a $1,300 deposit. They then add an ottoman that increases the total by $650.

The next request is chosen from the $4,550 balance after the addition. It is not another calculation from the original quote left on the desk. Once the further $700 arrives, the balance becomes $3,850.

If the total falls instead, the same principle applies: start with the revised total and subtract net money received. A customer-facing change also needs the appropriate revised agreement and signature. The payment record and the agreement should tell the same story.

The ottoman may look like a small addition beside the sofa. It is quite capable of causing a large afternoon of arithmetic if it lives only in an email.

Handle refunds without erasing the original payment

A refund is a financial event, not a correction that makes the original payment disappear. Keep the payment and refund visible so the team can explain the net amount retained.

OrderPilot records cash refunds made through its supported refund action and syncs card refunds and returns made in Shopify. A refund reduces the money retained. If the sale total is unchanged, that can increase the balance; if items or charges are also removed, the final balance depends on both changes.

For an illustrative $3,000 order with $2,000 paid, reducing the total to $1,800 creates a $200 amount to return. Refunding $200 leaves $1,800 retained against the revised $1,800 sale. Refunding without making the agreed order adjustment would describe a different financial position.

If a genuine overpayment arrives outside checkout, stop collection and reconcile it with the responsible back-office person. The app's collection caps should not be bypassed by entering an invented sale line or an inaccurate payment. Determine the correct refund or credit, record it through the proper route, and explain the outcome to the customer.

Give the customer the same current answer

Payment buttons on the portal, emails, and invoice PDFs give the customer a route back to the sale. A saved PDF is a snapshot, while the linked payment flow checks the current order's readiness.

After settlement, the customer's amount summary can show Paid. Staff should still use the history when answering a question about which payment covered the balance. “Paid” is a useful result, but the dated receipt explains how the result was reached.

For checks, wires, and financing receipts, use the outside-payment guide. For the final collection route, see payment link, POS, or invoice.

Review balances before delivery is promised

Make a weekly check of orders nearing handoff: current total, completed payments, open requests, refunds, and the amount due under the agreed terms. Assign unresolved items to someone before the delivery conversation starts.

Also keep the operational ledger separate from revenue recognition. An order can show a deposit received while the accounting treatment still follows the rules discussed in customer deposits and bookkeeping.

The customer should hear a confident amount supported by a readable history. Choose how to collect the final balance before the delivery call, and name who verifies it before the piece leaves.

Sources

1. Collecting and recording partial payments — Shopify, March 26, 2024.