Handling part-payments and credit notes in bulk payment runs

A payment run where every invoice is paid in full is easy. The runs that ruin an afternoon are the ones where a few invoices are short-paid, a couple are offset by credit notes, and one has a deduction nobody explained. Part-payments and credit notes are the reason a bulk run refuses to balance, and they are worth a deliberate method rather than improvisation.

Part-payments: the invoice stays open

A part-payment is when the customer pays less than the invoice's face value against that invoice on purpose, leaving a balance still owing. The mechanics in Xero are simple: you allocate the paid amount to the invoice, and the invoice remains partly outstanding for the remainder. The difficulty is not recording one part-payment; it is spotting, in a hundred-line run, which lines are short and by how much.

• Compare each remittance line to the invoice's outstanding balance, not just its total, in case earlier part-payments already reduced it.
• Record the exact amount paid; never round a part-payment to make a batch balance.
• Leave the remainder outstanding so it stays visible in aged receivables and gets chased.

Credit notes: money that reduces what is owed

A credit note reduces the amount a customer owes without cash changing hands. In a payment run, credit notes explain why a payment is smaller than the invoices it references: the payer has taken the credit into account. To reconcile correctly you allocate the credit note against the relevant invoice, then apply the cash to the remainder.

The common mistake is to treat the shortfall as a part-payment when it is actually a credit. The invoice then sits with a false outstanding balance forever, because the credit that should have cleared it was never applied. Always ask whether a shortfall is cash-short (part-payment) or credited (allocate the credit note), because the two are recorded differently and only one leaves a real balance owing.

Why bulk runs make both harder

Individually, a part-payment and a credit note are each a minute of work. The problem is volume and interaction. In a large run you cannot tell at a glance which lines are full, which are short, and which are credited, and the batch tools assume full payment. So you end up pulling the exceptions out of the batch, handling them one at a time, and reconciling the remainder, all while keeping a running total that has to land exactly on the deposit.

A repeatable method

• First pass: match and settle every line paid in full; these are the easy majority.
• Second pass: identify short lines and decide, per line, part-payment or credit note.
• Apply credit notes to their invoices, then allocate cash to what remains.
• Record part-payments at the exact amount, leaving remainders open.
• Reconcile: confirm the total of everything applied equals the deposit before posting.

This is exactly the kind of work a deterministic matching tool is built for. Given the remittance and the open invoices, whether a line is full, short or credited is knowable, and the exceptions can be surfaced for a human to confirm rather than found by eye. The judgement stays with you; the searching does not.