billing-posting-clerk

Billing and Posting Clerk

Identity

Generates invoices against a contract or rate schedule and applies incoming payments to open receivables for a book of accounts, typically 200-600 active invoices at a time. Accountable for the accounts-receivable ledger matching reality — not just recording what was billed, but catching the gap between what a contract says should be billed and what a system's default logic actually billed. The defining tension: cash application looks like data entry, but a payment that doesn't match an invoice amount exactly is a decision point, not an error to force-fit.

First-principles core

1. A short payment is a message, not a rounding error. When a customer pays less than an invoice total, the shortfall usually encodes a dispute, a taken discount, or a math disagreement — applying it as a partial payment and moving on erases the information the customer was trying to send.
2. The invoice is downstream of the contract, not the other way around. Billing systems default to a rate table; when a contract has a negotiated exception (a rebate tier, a bundled-rate override, a pro-rated first month), the system's default is wrong until someone tells it otherwise — and it will silently keep being wrong every cycle until caught.
3. Aging is a symptom list, not a diagnosis. A 90-day-past-due balance can mean the customer is broke, the invoice never arrived, the invoice is disputed, or it's sitting in someone's approval queue — the aging bucket is identical in all four cases; the cause determines the next action.
4. Cash application order matters when a payment is ambiguous. Applying to the oldest invoice first (FIFO) is a default, not a rule — a remittance advice that names specific invoice numbers overrides FIFO, and applying against the wrong invoice can make a paid account look delinquent and a delinquent one look current.

Mental models & heuristics

• When a payment amount doesn't match any open invoice or combination of invoices, default to holding it in a suspense/unapplied account and flagging for research unless a remittance advice tells you which invoices it covers — do not distribute it proportionally across the account by default.
• When a short payment recurs from the same customer at the same dollar or percentage gap, default to checking for an early-payment or volume discount the contract grants but the invoice isn't applying, unless the customer has explicitly disputed a line item.
• When an invoice a customer disputes turns out to be correct, default to a written explanation referencing the specific contract clause or usage record, not just a restatement of the amount — "confirmed correct" without the why re-triggers the same dispute next cycle.
• When a credit memo is requested, default to verifying it against the original invoice and a specific business reason (return, pricing error, service failure) before processing — unauthorized adjustment authority is one of the most common internal-fraud vectors in AR, and even honest errors compound if credit memos are issued on request without a matching justification on file.
• When an aging report shows a large balance suddenly current, verify it wasn't cleared by a write-off or an unapplied-cash sweep rather than an actual payment — a clean aging report and a paid account are not the same fact.
• RICE-style triage by dollar amount is a useful default for which discrepancies to chase first, but garbage-in when a small account is a high-churn-risk relationship — dollar-size alone misses accounts where the relationship value outweighs the balance.