Accounts Receivable Software: Balances and Collections

Accounts receivable software keeps every debit and credit with your customers (and, for payables, your suppliers) in one place and shows who owes how much, when it falls due and where collection stands. It has four parts: a customer ledger that stores every movement as a record that is never deleted, an aging report that groups open amounts by due date, a reminder flow for amounts coming due and overdue, and balance confirmations that compare your figure with the other side. A spreadsheet works for the first customers; once you sell on credit and receive partial payments, the answer to “how much does this customer really owe us” starts to depend on who you ask. This article covers the right data model, the collection flow, the split of work with your accounting software, and the ready-made vs custom decision. These are the topics we start with when we build receivables tracking as part of our corporate solutions.

Is receivables tracking the same as accounting software?

Partly. Accounting software keeps the official books: journals, trial balance, tax filings. Receivables tracking answers operational questions: sales wants to see a customer's open balance before taking a new order, finance wants to know whom to call this week. In a small business the customer module of the accounting package may be enough. When sales, shipping and collections are separate teams without access to the accounting package, a separate receivables view is needed. Set up correctly, the two systems do not compete: invoices and payments flow into accounting, and the receivables view gives operations visibility. We explain how that transfer is built in accounting software integration and the invoice itself in e-invoice integration.

The core: a balance is a ledger, not a field

The part most often built wrong is the balance. Adding a “balance” column to the customer record and updating it on every invoice and payment works for a month; but when an update fails halfway or two users post at the same time, the number quietly drifts and nothing shows why. The right model records every invoice, payment, refund and adjustment as a separate entry. The balance is the sum of those entries. A wrong entry is never deleted; it is corrected with a reversing entry. Amounts are stored as integers in minor units (cents), not decimals, or rounding differences pile up. The example below computes the balance and the overdue amount from the entries.

type LedgerEntry = {
  accountId: string;
  kind: 'invoice' | 'payment' | 'credit_note' | 'adjustment';
  amountMinor: number; // debit positive, credit negative (cents)
  dueDate?: Date;
  postedAt: Date;
};

export function summarize(entries: LedgerEntry[], today: Date) {
  const balance = entries.reduce((sum, e) => sum + e.amountMinor, 0);

  // Payments settle the oldest due invoice first (FIFO).
  let credit = -entries
    .filter(e => e.amountMinor < 0)
    .reduce((sum, e) => sum + e.amountMinor, 0);

  let overdueMinor = 0;
  const invoices = entries
    .filter(e => e.amountMinor > 0)
    .sort((a, b) => (a.dueDate?.getTime() ?? 0) - (b.dueDate?.getTime() ?? 0));

  for (const inv of invoices) {
    const covered = Math.min(credit, inv.amountMinor);
    credit -= covered;
    const open = inv.amountMinor - covered;
    if (open > 0 && inv.dueDate && inv.dueDate < today) overdueMinor += open;
  }

  return { balance, overdueMinor };
}

No entry in a customer ledger is ever deleted, only reversed. A system that derives the balance from its entries is the only one that can answer “where did this number come from” a year later without an argument.

Due dates and the aging report

A total balance does not tell the collections team whom to call first. The aging report does: open amounts are grouped by due date, and for each customer you see which amount has been waiting how long. For the report to be trustworthy, these rules must be set from day one:

• Every invoice has its own due date; it is copied from the customer's standard terms but can be changed per invoice.
• A payment knows which invoice it settles. If the user does not choose, the oldest due invoice is settled first.
• Buckets are fixed (not yet due, 1-30, 31-60, 61-90, 90+ days) and identical across all reports.
• Foreign currency accounts are tracked in their own currency; exchange differences are posted as separate entries.
• The report can be regenerated as of any date; last month's closing position does not change afterwards.

Payment reminders and the collection flow

Most collections come from reminders, and reminders need to be consistent. A scheduled job runs every morning, finds invoices coming due and overdue, sends the customer an email or WhatsApp message and logs the send on the customer record; the same invoice never gets two messages on the same day. We cover running that job safely in cron jobs and the messaging channel in WhatsApp Business API integration. A payment made through the link in the message is posted automatically as a payment entry when the payment provider's notification arrives; verifying that notification is the subject of webhooks. Customers who stay overdue for long leave the automated flow and become a task assigned to a person.

Balance confirmations and credit limits

A balance confirmation checks, as of a given date, whether the balance in your books matches the customer's. The software produces the confirmation letter with the statement of entries and records the other side's approval or dispute; if there is a dispute, the difference is examined entry by entry. For legal requirements and filings, ask your accountant; this article is not legal or financial advice. The credit limit is the sales-side counterpart: when the open balance and overdue amount exceed the limit, a new order goes to approval. Companies selling through dealers need this check at the moment of ordering; our articles on B2B dealer ordering and order tracking software explain that link.

Ready-made software or custom development?

For a business that mostly sells for cash and has one person watching receivables, the customer module of the accounting package or a ready-made bookkeeping tool is usually enough. Custom software makes sense when the balance must appear at once on order, shipping and field sales screens, when credit limits and approvals are specific to the company, when there are several branches and currencies, or when reminders must connect to existing channels. Who may post payments and who may change limits is a permissions question (user roles and authorization). For the general decision framework, see custom software vs ready-made.

Conclusion

Accounts receivable software is not a list of balances but a ledger that keeps every debit and credit with its date. In a well-built system the balance is derived from entries, records are reversed rather than deleted, the aging report becomes the collections team's to-do list, reminders go out on schedule and confirmation differences are resolved entry by entry. If you want to connect receivables to your ordering, shipping and accounting processes, see our corporate solutions or request a quote directly.