Selling on Account: Which Customer Owes What, and When Is It Settled?

Selling on account means letting a named customer complete a purchase while the amount remains due. Before adding that option to a till or business app, define who owes the money, which balance staff are seeing and how later payment clears the right purchases. An account payment must not look like cash already received.

A customer may also pay money in advance. Keep that position understandable without confusing it with credit granted by the business. This guide concerns operational requirements, not permission to lend, legal credit terms or accounting advice. Have those matters reviewed for your business before implementation.

Identify the debtor before completing the sale

A walk-in sale can sometimes proceed without a customer record. An on-account sale needs the intended debtor. Show the selected customer clearly at the point of confirmation, especially where staff routinely serve people with similar names.

The Odoo 19 customer-account documentation provides a concrete example: its payment-method configuration enables Identify Customer to require customer selection. It also notes that a customer statement may belong to a linked company rather than the individual contact. These are scoped product facts, not a reason to assume every system groups debt the same way.

For a trade customer, agree whether employees of one company share the company's account, who may buy against it and what staff must check. A contact relationship alone should not silently establish purchasing authority. Use invented organisations and contacts to demonstrate the approved arrangement.

Separate advance funds from money still owed

Odoo documents both deposits for future purchases and purchases on credit. It describes a purchase made through the customer account as debt until paid off. Your interface should make the meaning of the displayed position equally explicit.

Avoid an unexplained positive or negative balance. Label an amount as available advance funds or outstanding debt, include its currency and provide the entries behind it. Decide how a purchase using some advance funds and some newly granted credit should appear. That is a requirement to agree and test, not an assertion that the cited product handles every mixed case automatically.

The same source says effective unpaid-debt monitoring requires creating an invoice for the order or installing the Accounting application. Confirm the configuration your proposed workflow actually depends on. A working payment button is not evidence that its debt reporting has been set up.

Decide what the credit limit actually does

The Odoo page describes a maximum sales credit warning: the customer button changes colour and a warning icon appears. It explicitly says this does not prevent the sale from proceeding. Therefore a configured limit is not, by itself, proof of an enforced stop in that documented POS flow.

Choose your business rule deliberately. Is excess exposure advisory, does it require an authorised exception, or must the sale use another payment method? Define the balance included in the check, which account it covers and when it is checked. Ask how two tills selling on account at the same time affect that rule. Do not promise a hard limit if only a screen warning has been demonstrated.

Make settlement explain the remaining debt

A later payment needs a traceable link to the intended account and the purchases or invoices it settles. Odoo documents selecting orders or invoices to settle and validating the received payment. Your specification should also resolve partial payment, payment entered against the wrong account and correction of a mistaken entry through an approved process.

Do not erase an earlier sale to make the balance look tidy. Staff should be able to explain what was bought, what was paid and what remains due from recorded entries. Limit access to customer financial information to the roles that need it.

For acceptance, demonstrate a prepaid purchase, a purchase creating debt, a credit-limit breach and a later partial settlement. Repeat the relevant case with two contacts belonging to the same company and with simultaneous till activity if you use multiple registers. Use synthetic accounts and test payments, never real customer credit. Bring the debtor rules and these examples to a business-app project discussion: the deliverable is a usable account lifecycle, not just another payment label.