A client agrees to a $3,600 cabinet, pays $1,800 today, and owes the rest on delivery in nine weeks. Recording the $1,800 is the easy part — it is in your account, dated, done. Recording the other $1,800 is where most sellers stop, because there is nothing to record yet. It has not been paid. It is only a number someone agreed to. And that is exactly the fact that needs writing down, the same day, against the same order.
The short version
A deposit and a balance are two separate facts, not one line. The deposit is money that arrived, dated the day it did. The balance is money that was agreed but has not arrived — record it the same way, with no paid date, tied to the same order. Most tracking problems on custom orders come from treating the balance as something that does not exist until it is paid, instead of something that exists, unpaid, from day one.
Two facts, not one
Ask most sellers what they record when an order comes in, and the answer is the deposit — an amount, a date, maybe a payment method. The balance gets a mental note: "they owe me the rest." A mental note is not a record. It has no date, it is not attached to anything, and it disappears the moment you are thinking about a different order.
The fix is smaller than it sounds. Write the balance down at the same moment you write down the deposit — as its own entry, for the full amount still owed, with no paid date next to it, against the same order reference. Nothing about that entry changes until the customer actually pays, at which point you add the date it happened. Two entries, one paid, one not, both pointing at the same order. That is the whole model.
The reason this matters more than it looks is what happens when you stop at one row per order.
Why one row per order stops working
A single-row-per-order sheet — order, total, paid?, yes/no — survives exactly as long as every order is paid in one deposit and one balance, on schedule, in full. Three ordinary situations break it.
- The deposit is partial. A client pays $900 of a $1,800 deposit because that is what they have this week. "Paid?" is no longer yes or no — it needs an amount, and the balance figure needs to reflect what is actually still owed, not what was originally quoted.
- The deposit lands in two transfers. $1,000 on Monday, $800 on Thursday, same order. A one-row sheet either shows one payment that did not happen, or you are editing the same cell twice and hoping you remember which transfer you already counted.
- Something gets refunded. The order shrinks, a customer cancels part of it, or a deposit is returned. Now the row has to represent a number that went down after the fact, which a "paid" checkbox was never built to hold.
Every one of these is normal, not exceptional. A tracking system that only works for the clean case fails on exactly the orders that need the most attention — the ones that did not go as planned.
Recording it in a spreadsheet
A spreadsheet handles this fine if it has the right columns: order reference, total price, deposit amount, deposit date, balance amount, balance paid date (blank until it happens). Five or six columns, one row added per payment rather than per order, so a partial deposit or a second transfer is just another row instead of an edit to an existing one.
The column everyone forgets is the order reference on the balance row. It is easy to remember on the deposit — you are looking at the order when you take it. By the time the balance is due, weeks later, the temptation is to just note the amount and the date and skip the reference, because obviously you know which order it is. You do, today. You will not, three months and forty orders from now, when you are trying to answer "how much is still owed across everything open." That question, and what an order looks like while it is partly paid for months at a time, is the whole reason the reference matters. A more detailed comparison of where a spreadsheet holds up and where it does not — against accounting software and against a purpose-built tool — is in how to track deposits on custom orders.
Recording it in accounting software
In Xero or QuickBooks, the deposit typically goes to a liability account — customer deposits, deferred revenue, unearned revenue — and the balance sits as an open invoice or a manually tracked partial payment. Both platforms will hold both numbers correctly for what they are built to do: keep the books straight for tax purposes.
What neither one does natively is show the deposit and the balance as two halves of the same order, updating together. The liability account tells you how much you are holding against undelivered work in total. It does not tell you, on its own, which specific order that $1,800 belongs to, or what is still owed on it, without opening the invoice and checking. For a handful of orders that lookup costs a minute. For twenty open at once, it is the difference between a number you know and a number you have to go find. That gap — between what a general ledger tracks and what a made-to-order seller actually needs day to day — is the whole subject of why Xero and QuickBooks fall short for made-to-order sellers.
Recording it in a tool built for orders
The model that avoids both problems is the one above, run automatically: when an order is created, two records get written against it in one step. The deposit is booked dated the day the order was taken, which for most made-to-order work is the day it arrived. The balance is booked at the same moment, for the amount still owed, with no paid date attached — a figure that exists and is visible from day one, not a mental note that surfaces only when someone asks.
The balance record stays that way — present, unpaid, attached to its order — until the customer actually pays it, at which point it gets marked paid on the order itself and the date lands automatically. Nothing about the order needs to be re-entered, and nothing about the payment needs a second spreadsheet to explain which order it belongs to, because it was never separated from the order in the first place.
This is what Ordamo does with every order: one record for the money that arrived, one for the money that is promised, both against the same order, from the day it is created. You can see the shape of it on a live example — the public order page shows a customer exactly what has been paid and what is still owed, pulled from the same two records, not typed up separately for their benefit.
Stop keeping the balance in your head — see it recorded against the order from the day it's created.
See how it worksWhat "how much am I owed" costs in each one
The three approaches above are not different philosophies. They are different answers to the same question, asked across every open order at once, and the difference shows up in how long the answer takes.
| Spreadsheet | Xero / QuickBooks | Built for orders (Ordamo) | |
|---|---|---|---|
| Deposit recorded with the date it arrived | You type it in | Yes, as a payment or journal entry | Automatic, at order creation |
| Balance recorded before it's paid | Only if you add the row yourself | Only as an open invoice | Automatic, as an unpaid forecast on the same order |
| Both tied to the same order | One more column, easy to skip | Not by default — two separate records | Native — same order, two rows |
| Balance updates if the price changes | Manual edit | Manual edit on the invoice | Derived from the order — change the agreed price and what is owed follows |
| “How much am I owed, across every order?” | Add a column, keep it current | Open every invoice | One number, always current |
A spreadsheet answers the question in the time it takes to open it and trust that it is current. Accounting software answers it in the time it takes to open every invoice for every open order. A tool that records the deposit and the balance against the order itself answers it in the time it takes to look at the screen.
What to keep for the accountant
None of this replaces the accounting question, and it is not meant to. Whatever you use to record deposits and balances day to day, your accountant needs the same three things at year end: every deposit with its date and amount, every balance with whether and when it was paid, and the order each one belongs to. Whether that deposit is booked as a liability until delivery or handled some other way is a separate question, answered in full in is a customer deposit income.
An export in that shape — order, deposit amount and date, balance amount and paid date — is what turns the day-to-day recording above into the entries your accountant actually needs, without them reconstructing which payment belonged to which order from a bank statement.
The bottom line
A deposit and a balance are two facts about one order, not one fact with a follow-up. Record the deposit with the date it arrived. Record the balance the same day, for the amount still owed, with no paid date — and only add one once it is actually paid. Do that consistently, in a spreadsheet, in accounting software, or in a tool built to do it automatically, and "how much am I still owed" stops being a question you have to go answer and starts being a number you already have.
Frequently asked questions
How do I record a deposit and a balance for the same order?
Record them as two separate facts, not one. The deposit is money that has arrived — write it down with the date it landed. The balance is money that has been agreed but not paid — write it down as a figure attached to the same order, with no paid date, so nothing marks it as collected until it actually is.
Is a customer deposit income when I record it?
That is an accounting-treatment question, not a recording-mechanics one — short answer, it is generally a liability until delivery, not income on the day it arrives. The full reasoning, the year-end example and the tax question live in is a customer deposit income, linked below.
What's the one column everyone forgets in a deposit spreadsheet?
Which order the payment belongs to. Amount and date are easy to remember; the order reference is the column that gets skipped when you are typing fast, and it is the one that makes the sheet useless the moment two orders are open for the same customer at once.
Should I record the balance before or after it's paid?
Before. Record the balance the moment the price is agreed, as an amount owed with no paid date, at the same time you record the deposit. Waiting until the balance actually lands means it exists nowhere until the day it is paid, which is exactly the gap that makes 'how much am I still owed' unanswerable without opening every order.
Can Xero or QuickBooks track a deposit and balance against one order?
They can hold both amounts, but not as one linked figure that updates itself. You post the deposit to a liability account and the balance sits as an open invoice; nothing in either ledger says the two rows are the same order, so answering 'what's owed on this order' still means finding both entries by hand. More on where that gap sits in why Xero and QuickBooks fall short for made-to-order sellers, linked below.
What happens to the balance record if the price changes mid-order?
Update the balance figure to match the new agreed price. In a spreadsheet that means editing the formula and hoping nothing downstream referenced the old number; in a tool built around orders, the balance is derived from the order total minus what has been paid, so it updates itself when the total changes.
What do I actually need to hand my accountant at year end?
Every deposit with its paid date and amount, every balance with whether it was paid and when, and the order each one belongs to. That is three columns per payment, repeated for every order — an export of exactly that shape is what your accountant turns into the liability and revenue entries described in is a customer deposit income.
Every order, deposit and balance recorded automatically, tied to the order they belong to.
See Ordamo