Customer receipts should close the right invoices - not create another reconciliation problem
A customer receipt connects money received with the customer account, open invoices, bank activity, receivables, and the general ledger. The difficult part is handling real payment behaviour without losing the audit trail.
Updated September 26, 2026 · Practical ERP capability guide
What a customer receipt means in ERP
A customer receipt records incoming funds and identifies who paid, when the payment arrived, the method and reference, the bank account, currency, amount, and invoices affected. Settlement reduces open receivables; it should not erase the invoice or hide the payment that cleared it.
One receipt may settle one invoice, several invoices, part of an invoice, or no invoice yet. Overpayments, short payments, discounts, fees, refunds, unidentified cash, and disputed balances require explicit treatment.
Problems finance teams search for
- A payment arrived but the invoice still appears overdue.
- One deposit covers several invoices and allocation is unclear.
- The customer paid less or more than expected.
- A receipt was posted to the wrong customer or bank.
- Bank activity, accounts receivable, and the general ledger disagree.
These are not receipt-layout problems. They are transaction identity, settlement, posting, permission, and correction problems.
How Simor ERP supports the workflow
Customer Receipts sits inside Simor ERP Accounting and connects to customers, sales invoices, bank accounts, journal entries, the general ledger, aging, and financial reporting. Users can record the receipt, apply it to the appropriate invoice balance, and retain the relationship between the cash event and its source documents.
Because sales delivery, invoicing, receipts, COGS, revenue, and receivables are part of one system, a finance user can move from an aging balance to the invoice and related receipt instead of rebuilding the story across unrelated files.
Controls to verify
Cash application becomes difficult when bank information does not identify an invoice cleanly. A payer may use a parent-company name, combine several branches in one transfer, deduct a credit memo, take an unapproved discount, or send money before the invoice exists. The workflow needs an unapplied state so finance can record real cash without inventing a settlement.
Partial receipts require an explicit remaining balance. Closing the invoice automatically can hide a collection issue; leaving a negligible balance open forever can distort aging. Tolerance, write-off authority, cash-discount treatment, and approval depend on company policy. Microsoft’s documentation likewise distinguishes partial settlement, full settlement, discounts, and configured overpayment or underpayment handling.
Reporting and implementation questions
Receivables reporting should distinguish open invoices, partial settlement, unapplied cash, customer credits, reversals, and disputes. The bank register shows the cash movement, while the general ledger shows the control-account effect. Useful measures include days to apply cash, unapplied value by age, reversed receipts, and short-payment frequency.
- Can one deposit cover several invoices or customers?
- Who approves write-offs, discounts, refunds, and corrections?
- Which references arrive through banking integrations?
- What receipt or notification does the customer receive?
- How are corrections handled after reconciliation or close?
Simor ERP can adapt fields, approval limits, reports, and integration points around these decisions. The configuration should reflect the receivables policy rather than force every exception into one generic action.
Background reading: Microsoft guidance on partial customer payments and customer payment settlement workflows.
Prevent duplicate application
References and invoice balances should help detect a receipt entered twice. Concurrent settlement must not allow two users to clear the same remaining balance.
Preserve correction history
A mistaken allocation should be reversed or corrected through a governed path. The original posting, correction, user, time, and resulting invoice balance should remain explainable.
Reconcile three views
Open customer balances, bank activity, and general-ledger control accounts should be reviewed together. A matched bank line is not automatically proof that the correct customer invoice was settled.
Example: one deposit, three open invoices
Suppose a customer sends one bank transfer covering two invoices in full and part of a third. The person applying cash needs to identify the payer, confirm the bank and currency, select the open documents, record the remaining balance, and preserve the customer's payment reference. If the short balance represents a dispute rather than a timing difference, it should remain visible instead of being silently written off.
A useful review screen should show the original invoice amounts, prior applications, the amount being applied now, and the balance after posting. The resulting receipt should be traceable from the customer account, each affected invoice, the bank register, and the journal entry. If the allocation is later corrected, reviewers should be able to distinguish the original event from the reversal and replacement.
This scenario is worth testing with duplicate references, an overpayment, a closed fiscal period, and a user without approval authority. Those cases reveal whether the workflow is genuinely controlled or only works for a perfect payment.
Cash-application scenarios to prove before launch
Before go-live, test a receipt applied to one invoice, several invoices, and only part of an invoice. Repeat the exercise with an overpayment, unknown payer, credit balance, foreign currency, duplicate bank reference, closed accounting period, and receipt later reversed. Two users should not be able to consume the same outstanding balance concurrently.
Verify that customer aging changes by the applied amount, the bank register contains the cash event, the journal remains balanced, and reports drill back to the same receipt. Then confirm that unauthorized users cannot approve a write-off, redirect the bank account, or alter a posted allocation without an auditable correction.
The final design should also specify how unapplied money is followed up, how customers are contacted about ambiguous remittances, and which role owns exceptions that remain unresolved at month-end. Those operating details determine whether the feature reduces work or simply moves uncertainty into a new screen.
Review the capability
Follow the broader order-to-cash process, review Simor ERP accounting, or open the live ERP demo before discussing receipt forms, integrations, and delivery.