Learning

Why a Customer Prepayment Isn’t a Negative Receivable

You open a customer’s account and the balance is negative. Your AR aging shows them at minus $450.

Most systems will do this without complaining, and the arithmetic works out — the total receivables figure comes to the right number once you net the credit against everyone else’s balances. It still isn’t right.

How it works

A customer holding a credit does not owe you a negative amount. They owe you nothing. You owe them — $450 of service you have been paid for and not yet delivered.

Those are two different things in every direction that matters. A receivable is money you expect to collect. It is an asset. It is something you chase, age, and eventually write off. A liability is an obligation you expect to settle. It is something you deliver against.

Booking a prepayment as negative AR gets both sides of the balance sheet wrong at once. It understates your receivables by the amount of the credit, and it omits the liability entirely. The balance sheet still foots, because the error cancels itself. That is exactly why nobody catches it.

It also quietly corrupts your aging report. AR aging is a collections tool — it exists to tell you who to call. A customer sitting at minus $450 in that report is not “very early on paying”; they are in the wrong report altogether, dragging the total down and making every number computed from it slightly wrong.

In BasicBMS both numbers are shown, and both are right. A customer holding a credit appears at $0.00 in AR aging — there is nothing to chase — while separately holding a $450.00 credit balance in Deferrals. Neither figure is netted against the other, because they are not the same kind of thing.

And the credit has an owner. A general ledger that shows $12,000 of deferred revenue tells you the total and nothing else. It does not tell you whose money it is. In BasicBMS the credit is attached to a named customer, resolved from their SoldTo contact, so the liability is attributable to the person you owe it to rather than being a lump sum in an account.

What posts behind it

Two entries across the life of a credit. When the prepayment arrives:

On saving the payment

	Account	Debit	Credit
DR	Cash	1,475.00	—
CR	Accounts Receivable	—	1,175.00
CR	Deferred Revenue	—	300.00
	Balanced	1,475.00	1,475.00

Cash goes up by what the bank actually received. The receivable clears by what the payment settled. The remainder becomes a liability.

When the next invoice is issued, the credit is drawn down against it, oldest credit first, and the liability comes off the books as the service is delivered:

On issuing the next invoice

	Account	Debit	Credit
DR	Deferred Revenue	300.00	—
CR	Accounts Receivable	—	300.00

The customer’s balance never goes negative at any point in that sequence, because at no point were they owed money by you and recorded as owing money to you.

When it won’t let you

This is worth dwelling on, because it is the same principle as the rest of this article. The system could pick a plausible account and move on. It doesn’t, because a wrong entry that balances is harder to find than no entry at all. Software that balances is not the same as software that is correct.

Stuck on this one? Call (509) 949-2162 and we’ll walk through it with you.