Cash application

Matching payments to what they actually settle

Customers in Australia pay through several rails: direct bank transfer, PayID, BPAY, card and, less often now, cheque. Each one lands differently in your bank feed, and each one needs to be matched back to the invoice or invoices it settles before your receivable balance means anything.

Why the rail matters

A BPAY payment often lands as a single lump sum covering several invoices with no reference beyond a biller code, while a direct transfer might carry a customer's own note instead of your invoice number. Each rail needs its own matching logic rather than one generic rule, which is why we treat BPAY, PayID and card settlements as separate patterns, not a single feed to guess at.

Partial and unmatched payments handled, not guessed

When a payment does not match an invoice cleanly, whether it is a partial payment, an overpayment or an amount that simply cannot be identified yet, we hold it as an open item and ask you rather than applying it on a guess.

Fees separated from the gross amount

Payment processor and merchant fees are stripped out of the gross amount received so the revenue and the cost of accepting payment are both visible, not blended into one number.

Keeps your ageing report honest

Because cash application happens as payments land rather than in a batch at month end, your accounts receivable balance and ageing report stay current through the month, not just accurate on the day we run the report.

Fewer surprises at BAS time

When cash application lags, GST on sales can be reported based on invoices that were actually settled weeks earlier through a different rail than the bank feed shows, which creates reconciling work right when your tax agent needs clean numbers for the quarter. Keeping application current avoids that scramble.