FIFO Payment Allocation Explained: Why the Oldest Invoice Should Be Paid First

If your business sells on credit, you already know the headache: a customer has three or four open invoices, they send a partial payment, and someone has to decide by hand which invoice that payment covers. FIFO payment allocation removes the guesswork by applying a simple, consistent rule — and it's what Hisaabkar uses automatically every time a payment is recorded.

What FIFO allocation means

FIFO stands for "First In, First Out." Applied to payments, it means: when a customer pays you, the payment is applied to their oldest outstanding invoice first. Once that invoice is fully settled, any remaining amount rolls forward to the next-oldest outstanding invoice, and so on, until the payment is fully allocated.

This mirrors how most businesses actually think about a customer's account — as a running balance, not a pile of disconnected bills. It also matches how most customers expect their payment to be treated: "I paid you Rs. 20,000, please apply it to what I owe you the longest."

A simple worked example

The numbers below are a simple illustrative example, not a real customer, chosen with round figures to make the mechanics easy to follow.

Suppose a customer, "Example Traders," has three outstanding invoices:

• Invoice #101 — issued first — outstanding balance: Rs. 10,000
• Invoice #102 — issued second — outstanding balance: Rs. 15,000
• Invoice #103 — issued third (most recent) — outstanding balance: Rs. 8,000

Example Traders sends a payment of Rs. 22,000. FIFO allocation works through the invoices oldest-first:

1. Invoice #101 (Rs. 10,000 owed) is paid off completely. Rs. 12,000 of the payment remains.
2. Invoice #102 (Rs. 15,000 owed) receives the remaining Rs. 12,000, leaving Rs. 3,000 still outstanding on #102. The payment is now fully used up.
3. Invoice #103 (Rs. 8,000 owed) is untouched — it stays outstanding until the next payment.

After this single payment, the customer's account shows Invoice #101 as paid, Invoice #102 as partially paid (Rs. 3,000 remaining), and Invoice #103 as fully outstanding — all without anyone manually deciding which invoice the money should go toward.

FIFO allocation turns "which invoice does this payment cover?" from a judgment call into a rule the system applies the same way every time.

Why this matters for accurate receivables

Without a consistent allocation rule, two people recording payments for the same business can allocate the same payment differently — one applies it to the newest invoice, another to whichever invoice the customer mentioned on the phone. Over months, this drifts your accounts receivable ageing report out of line with reality: invoices that are actually settled still show as outstanding, or vice versa. A single, automatic rule keeps every payment allocated the same way regardless of who recorded it, which keeps your ageing report, customer statements, and ledger trustworthy.

Why oldest-first, and not newest-first or manual choice?

You could imagine other rules — apply a payment to whichever invoice the customer mentions, or to the most recent invoice, or split it evenly. In practice, each of those introduces a decision that has to be made consistently by every staff member, every time, or the ledger drifts. Oldest-first has a practical advantage beyond simplicity: it naturally keeps your oldest, most overdue balances shrinking first, which is also usually what you'd want to prioritise if you were deciding by hand. It converts a judgment call your team would otherwise have to make consistently into a rule the system applies the same way, every time, without anyone needing to remember the policy.

A second example: multiple payments over time

FIFO allocation isn't a one-time calculation — it applies fresh every time a new payment comes in, based on whatever is still outstanding at that moment. Continuing the Example Traders scenario: after the Rs. 22,000 payment above, the account stands at Invoice #102 with Rs. 3,000 remaining and Invoice #103 fully outstanding at Rs. 8,000. If Example Traders then sends a second payment of Rs. 5,000 a week later, FIFO again starts from the oldest open balance: Rs. 3,000 clears the rest of Invoice #102, and the remaining Rs. 2,000 is applied to Invoice #103, leaving Rs. 6,000 still outstanding there. Nobody needs to remember what was settled last time — the system always allocates against whatever is currently oldest and open.

What happens on overpayment

Continuing the example above: if Example Traders had instead sent Rs. 40,000 as the first payment, FIFO would clear #101, #102, and #103 in full (a total of Rs. 33,000), leaving Rs. 7,000 unallocated. Rather than that extra amount sitting in limbo, Hisaabkar records it as a customer credit balance. The next time an invoice is raised for that customer, the credit balance is automatically applied first, reducing what they owe — no manual adjustment entry needed, and no risk of double-charging a customer who's already overpaid.

This also protects against a common source of ledger confusion: a customer who pays a round number "on account" without specifying which invoice it's for. Instead of that payment sitting unapplied until someone manually matches it, FIFO allocation and credit balancing handle it immediately, and the customer's next invoice already reflects any credit they're owed.

How this shows up in your ledger and ageing report

Every payment you record is visible on the customer's ledger with exactly which invoice, or invoices, it was allocated against — so if a customer calls asking "what did my last payment cover?", the answer is a lookup, not a recalculation. Because outstanding balances always reflect real, current allocation rather than a rough running total, your receivables ageing report — which groups balances by how long they've been outstanding — stays accurate without manual cleanup at month-end.

See it in your own ledger

You don't need to calculate any of this by hand. Record a payment against a customer in Hisaabkar and the allocation, the updated outstanding balances, and any resulting credit balance are handled automatically and reflected immediately in the customer ledger and ageing report. Read more allocation examples in the Help Centre, or start recording payments in Hisaabkar today.