Finance · Billing · Payments
Revenue Accounting
Everything about how money reaches KISS's books, in one place — how customers pay (card, ACH, wire, check), the deposits those payments create, the moment revenue is actually recognized, and how sales commission and royalty are accrued and paid. The revenue-side companion to Inventory Accounting (the cost side) and the accounting story behind Working with Quotes.
The principle under everything: their money is in before ours goes out. Accounts Receivable means only one thing here — shipped and still owed.
How an order runs
No QBO invoice is created at signing — the signed quote page is the bill. Money the customer pays sits as a deposit (a liability we owe them) until the order is paid in full; only at fulfillment does it become revenue. Every step below posts itself.
| Stage | What happens | Books impact |
|---|---|---|
| Signing | F21 books the order (status booked), builds the Inflow SO + payment schedule. No invoice. | Nothing — zero AR, zero revenue |
| Collections | Customer pays against the quote page; each receipt is a Sales Receipt (item 364) with the quote ULID in the memo. | Dr Cash / Cr 2300 Customer Deposits |
| Paid in full | F22 (hourly) sees every milestone covered. | Dr 2300 / Cr 2200 Deferred HW Revenue |
| Fulfillment | Ship in Inflow → F3 creates the fulfillment invoice + posts COGS and commission/royalty. | Revenue → 4100 · COGS · comp |
The rep writes the schedule
The default. Leave the payment date blank on the line items and this is what you get.
Put a payment due date on each hardware line. Those dates are the schedule, exactly as written. Available on any timeline — there is no minimum runway.
deposit_percent (20–99%) and, if you want, a deposit due date. The balance falls on the declared dates.Nothing ships until it's paid in full.
That's the rule, and as of 30 Jul 2026 it is the only one (rare exceptions need Michael's sign-off). We used to also stage the money against the delivery date — a check-in at 90 days out that billed to 60% and "went hard", a balance at 30 days out, and no deposits at all inside 90 days. Every one of those dates was invented by the system rather than agreed with the customer, and they existed to keep your cash ahead of our committed cost. Collecting in full before anything leaves the building does that on its own, so they are gone.
This is deliberately the loosest version that works. If it starts to squeeze cash flow, we will add a restriction back then, against real evidence — not in advance.
How customers pay
Four rails, and they all end in the same place: a QBO Sales Receipt using item 364 “Hardware Deposit”, which credits 2300 Customer Deposits. That shared ending is deliberate — it's what gives us one reconciliation path instead of four. What differs between rails is only which bank account the receipt deposits into, and how much of it a person has to do.
| Rail | Deposits into | Who does what | Fee? |
|---|---|---|---|
| Credit card | 1130 Stripe Clearing | Fully automatic | Stripe's cut, at payout |
| ACH (US bank) | 1115 Ramp Operating | Fully automatic, 1–5 day settle | Occasional Intuit fee |
| Wire (international) | 1110 Operating | You record it; bank charges are common | Often — see below |
| Check / outside payment | 1110 Operating | You record it from the Orders drawer | Rarely |
! One exception that overrides all of the above: if an order already carries a QuickBooks invoice, it collects through AR, not through a Sales Receipt. Receive the payment against that invoice in QuickBooks and it flows back automatically. Posting an item-364 receipt on an invoiced order books the cash twice.
💳 Credit card
The customer enters their own card — on their bill page, or at the last step of signing. Hardware is customer-present only; we never auto-charge a stored card for it (that was retired in June 2026 after off-session declines caused more trouble than the automation saved). The recurring premium subscription is the only thing kept on file.
The amount is derived on the server from the open milestone, and the charge is claimed before it runs, so a double-click or a browser closed mid-payment can't double-charge. Seconds after capture the receipt posts into 1130 Stripe Clearing, the milestone flips to collected, and the customer is emailed a receipt. Nothing for you to do.
Dr 1130 Stripe Clearing / Cr 2300 Customer Deposits — at the gross charge amount.The part people get wrong. Stripe holds that money for a couple of days, then pays out a batch, net of its fees, into the bank. That deposit is not a sale — the sale was already recorded above. Categorize it as a Transfer from 1130 Stripe Clearing, and send the shortfall to 6390 Bank and Merchant Fees. Treat it as income and you've booked the same money twice.
Because 1130 takes charges in gross and pays out net, the fees accumulate there. Once a month, journal them out to 6390 and check the balance: 1130 should equal charges collected but not yet paid out. A balance far larger than a few days of charges means payouts aren't being cleared against it.
🏦 ACH — US bank
The customer enters their bank details on the bill page, per payment. It submits as an eCheck and takes 1–5 business days to settle, so the order shows a ⏳ Processing pill in the meantime and is deliberately kept out of the chase list — the team used to hound customers who had already paid. The receipt posts only on settlement, into 1115 Ramp Operating.
Dr 1115 Ramp Operating / Cr 2300 Customer Deposits — on settlement, not on submission.
!
A held eCheck never clears itself. If Intuit puts a risk hold on it the status stays
WITHHELD — and it will not flip to settled even after the money actually
funds. We've seen a funded $11.4k eCheck sit held indefinitely. Those get a Slack alert on
every poll; clearing one is a manual procedure, so ask before forcing it.
🌍 Wire — international
Offered on non-US ship-to only (domestic wire is a deliberate future addition, not an oversight). Wire orders get a KISS-branded instructions PDF attached to their welcome email, and the quote ULID is the payment reference — that's what lets the payment be matched back to the order. Record the arrival with Record outside payment in the Orders drawer, exactly as for a check.
Expect the deposit to be short, and record the gross anyway. Intermediary and
receiving banks take their cut in transit, so $34,734.14 sent can arrive as
$34,685.81. The customer paid in full — the $48.33 is our expense. Enter what the
customer sent, then resolve the difference to 6390 when you match the deposit
in QuickBooks. The wire narrative itself usually itemises the charges
(/CHGS/USD23,33/), which is how you tell a bank fee from a genuine short-payment.
✉️ Check & other outside payments
A paper check, or any payment that lands straight in the bank with no rail behind it. Customers often select ACH at signing and then mail a check — that's fine, and it's why this exists. In the Orders drawer: Record outside payment → amount, bank date, and how it arrived.
The one field to get right
Bank date is the day the money hit the account, read off the statement — not the day you're recording it. It becomes the receipt date, which is what QuickBooks matches the deposit against, and it decides which month the cash lands in.
It has no default for exactly this reason. A wire that lands on the 31st and is keyed on the 2nd would otherwise post into the wrong month.
What happens next
The receipt posts to 1110 Operating dated that day, the milestone flips to collected, the order leaves the chase list, and the customer gets a receipt.
In QuickBooks the deposit will be offered as a Match against that receipt — that's the whole point of using the bank date.
Dr 1110 Operating / Cr 2300 Customer DepositsThree rules that hold on every rail
- Record the gross, never the net. If a fee was withheld, the receipt still shows what the customer paid, and the fee goes on its own line to 6390. This isn't bookkeeping taste — the sync that reads receipts back keeps our collections ledger equal to the sum of the item-364 lines, so a receipt posted net silently un-collects the milestone within a couple of hours, and the paid-in-full step then never runs.
- A payout is a transfer, not income. True of Stripe payouts and of any bank sweep. The sale was recorded when the customer paid.
- One system per rail. Never point a second Stripe→QuickBooks sync at the books — ours already does it, and it's the one that drives the milestone schedule, paid-in-full, and revenue recognition. A parallel sync isn't a safety net; it silently doubles everything. That happened in July 2026 and cost ~$47k of phantom revenue.
Revenue is recognized at fulfillment
When an order ships, F3 creates a QBO fulfillment invoice — the SKU lines book Hardware Revenue (4100) and real sales tax — and posts a companion journal entry for COGS, commission, and royalty. How the invoice is settled depends on whether the customer has paid yet. Both paths recognize the same revenue; they differ only in where the offset comes from.
Paid, then shipped the normal case
The invoice draws the whole amount down from Deferred Revenue (2200), so it nets to a $0 balance — no receivable. The money was already in; fulfillment just turns it into earned revenue.
Shipped before fully paid the exception
The invoice draws down whatever's been collected from Customer Deposits (2300) and leaves the rest as True AR (1200) — the one time AR is real. Later payments clear that AR, and when the invoice hits $0 the order flips to complete.
Commission & royalty — three legs
Commission and royalty ride two bridges (a deferred asset and an accrued payable) across three moments. The expense hits the P&L at fulfillment (matched to revenue); the obligation to pay sales is recognized at paid-in-full; the cash goes out through Gusto.
Rule of thumb: any order paid in full in a month is comped on the following month's run — and "paid" means the full balance, not a deposit. F1 accrues monthly on that paid-in-full basis; F2 calculates the payout and hands it to Gusto (royalties quarterly). For an order shipped before it's paid, the expense and the payable are booked together at fulfillment instead of using the deferred bridge — same end result.
Traps
A short list of places the books have been wrong in practice, kept separate because each one looks like ordinary work at the time. They share a shape: two systems record the same money, and the second record is the one someone creates by hand. If a trap here keeps recurring, promote it into the body of the playbook rather than leaving it in a list.
| Trap | Why it happens | What to do |
|---|---|---|
| Gusto lines in the bank feed | Gusto posts payroll as a journal entry, and QuickBooks filters journal entries out of the matcher's default view. The bank line therefore looks unmatched when it is already fully recorded. | Never categorize a GUSTO line and never record it as a transfer. In Find match set Record type to Journal entries and widen the dates, since the JE carries the period-end date while the cash moves days later. If it still will not surface, Exclude the line. First confirm the Gusto JE exists: if the sync failed, the bank line is the only record and does need booking. |
| Ready Steady Store, every month | The Stripe path posts both an Invoice (revenue to 1201 AR-EUR, memo in_…) and a Sales Receipt (revenue to 1131, memo py_…) for the same charge. |
The Sales Receipt is the real one. Void the invoice. Worth a look at every close: any open balance on customer Ready Steady Store-EUR whose memo starts in_ is an unvoided duplicate. |
The accounts
Anything unexpected in these accounts is a process exception worth investigating.
| # | Account | Holds |
|---|---|---|
| 2300 | Customer Deposits | Cash on an order not yet paid in full. Refundable up to fulfillment — the T−90 “goes hard” commitment point was retired. |
| 2200 | Deferred Hardware Revenue | Paid-in-full orders awaiting fulfillment. |
| 1200 | Accounts Receivable (True AR) | Only fulfilled orders with cash still owed. Never bookings, never deposits. |
| 4100 | Hardware Revenue | Recognized at fulfillment. |
| 5101 / 5500 / 5600 | COGS: Hardware / Commission / Royalties | Recognized at fulfillment. |
| 1410 / 1420 | Deferred Commissions / Royalties | Comp on paid-but-not-yet-fulfilled orders. |
| 2150 / 2160 | Accrued Commissions / Royalties Payable | Comp owed; cleared by the Gusto payout. |
Keep this playbook in sync with
- Recognition — workflow F3 (fulfillment invoice + COGS/commission/royalty JE, both paid and unpaid paths).
- Deposits & paid-in-full — the collection engine, F22 (2300→2200), and receipt posters F23 / F31.
- Commission / royalty — F1 (accrue at paid-in-full) and F2 (payout → Gusto). Don't touch the Gusto→QBO 2150 coding.
- Paid-after-shipping — F15 stamps the fulfillment invoice complete when it clears.
- The deep version — the LLM file (accounts, JEs, workflow IDs, the true-up) and
n8n/commission-royalty-trueup.md.