Partial & split payments
Two checkout flavours that aren’t just “Cash, full amount”. Partial lets the customer pay some now and walk out with the goods, with the rest sitting on their tab as debt. Split lets one sale be paid with two or three methods at once — half cash, half card, plus 200 in store credit. The shape of each in the journal is different; this page is the cheat sheet for both.
Partial — pay some, owe the rest
Partial is the pay-later flow. The customer is known to you, you trust them to settle next visit, and the unpaid balance lands on their account.
Build the cart and attach a customer
A customer is required for partial. Without one, there’s nowhere to file the debt — checkout will block.
Open Checkout, pick Partial
Choose payment type Partial. Two fields appear — paid amount and owed amount. Edit either and the other recalculates.
Enter the deposit (or zero) and complete
If the customer hands over 200 on a 500 sale, enter 200 paid. If they’re walking out with no cash today, enter 0. The remainder lands on amountOwed for this invoice and the customer’s balance increases by the same.
What posts to the books — partial
For a 500 sale with 200 paid in cash:
- DR 1010-xxx (cash sub-account) 200
- DR 1100 (Accounts Receivable) 300
- CR 4010 (Revenue) 500 (plus VAT split to 2020 if applicable)
- CR 1200 (Inventory) at FIFO cost; DR 5010 (COGS) for the same.
Settlement comes through Pay debt when the customer comes back — DR cash sub-account / CR 1100, FIFO-allocated across the customer’s open invoices oldest-first.
Split — multiple methods, one sale
Split is for the customer who hands you 300 cash and a card for the rest, or the wholesale buyer who pays half by transfer and half by card. The sale is fully paid at the register; the 2 or 3 methods are recorded against the same invoice.
Pick Split in checkout
Toggle Split in the checkout dialog. A method picker opens. Add as many methods as you need; each row takes a method and an amount.
Methods must reconcile to the total
The dialog runs a live total at the bottom. Sum of method amounts must be ≥ invoice total. If you’re under, checkout blocks. If you’re over on a method that has a cash sub-account configured, the overage becomes change due — see below.
Complete the sale
The invoice is issued with paymentType='split' and the methods are persisted on splitPayments. The Status badge on the list shows Split in purple.
What posts to the books — exact-match split
Cash 300 + Card 200 on a 500 sale:
- DR 1010-xxx (cash sub-account) 300
- DR 1020-xxx (card terminal account) 200
- CR 4010 (Revenue) 500
- CR 1200 / DR 5010 as usual.
Three lines on the debit side, balanced. Trial Balance reconciles cleanly.
The cash-overpay scenario
The interesting case: total 500, customer hands over Cash 1000 + Card 200, and you need to give back 700 cash as change. Pre-v1.6.99 builds rejected this at checkout; v1.6.99 added a fourth JE line so the journal balances against the actual sale, not the gross paid.
Quick comparison
| Partial | Split | |
|---|---|---|
| Customer required | Yes | No |
| Methods at register | 1 | 2 or more |
| Money still owed after checkout | Yes (amountOwed > 0) | No |
| AR ageing | Yes — on 1100 | No |
| Status badge | Partial (yellow) | Split (purple) |
| Settlement flow | Pay debt | None — done at checkout |
Related
Pay later & COD
The full pay-later mechanics, plus how cash-on-delivery shipments differ in the journal.
Pay debt
FIFO allocation across open partial invoices when the customer comes back to settle.
Invoice detail
Where the payment-method chips, owed amounts, and change-due rows render.