Customer Receipts: 7 Problems That Distort Receivables and Disrupt Monthly Close

The transition from manual ledgers to integrated ERP systems promised automation and accuracy, yet many organizations fail to harness its full potential. The root of the problem often lies in poorly configured workflows, procedural gaps, and a lack of understanding of the profound accounting implications of each step—from capturing a payment to its final reconciliation. When a bank transfer is posted without its value date, a partial payment is left unallocated, or a post-dated cheque is treated as cash, the integrity of the financial statements begins to erode. These are not isolated incidents but symptoms of a systemic weakness that can obscure a company’s true financial health and expose it to unnecessary risks.

This article moves beyond surface-level descriptions to provide a deep, technical analysis of the seven most pervasive problems in receipt voucher management that distort customer receivables and disrupt the financial closing cycle. We will dissect the mechanics of each issue, explore its root causes within the ERP environment, and delineate precise, actionable solutions grounded in best practices for accounting, internal control, and system configuration. The objective is to equip financial leadership with the knowledge to transform their receipt-to-reconciliation cycle from a source of operational drag into a strategic asset that delivers real-time visibility and control.

Problem 1: Receipts Without Allocation to Specific Invoices

Problem: One of the most common and corrosive issues in accounts receivable management is the practice of posting customer payments as “on-account” credits rather than applying them directly against the specific invoices being settled. The receipt voucher is created, cash is debited, and the customer’s AR account is credited, but the transaction sits as an unapplied balance, failing to close the corresponding open receivables. This creates a distorted view of the customer’s account, showing both aged, overdue invoices and a separate, unlinked credit balance.

Root Causes: This issue stems from a combination of process and system deficiencies. Operationally, the customer may not provide clear remittance advice indicating which invoices are being paid. The accounts receivable team, under pressure to post cash quickly, may opt to post it “on-account” with the intention of allocating it later—a task that is often forgotten. From a system perspective, the ERP may lack mandatory allocation rules or intelligent matching suggestions. If the system allows a receipt voucher to be saved and posted without forcing the user to select an invoice, it encourages this poor practice.

Impact: The consequences are severe. Firstly, the Accounts Receivable Aging report becomes highly unreliable; it shows invoices as overdue when they have, in fact, been paid. This artificially inflates Days Sales Outstanding (DSO) and can lead to misguided collection efforts, damaging customer relationships. Secondly, it complicates credit management, as a customer’s true outstanding balance is not immediately clear. Thirdly, these unapplied credits represent a financial liability and can create significant reconciliation challenges during account reviews and the month-end close. Over time, these balances become financial “noise,” requiring extensive manual effort to clean up.

Solution: The ERP must be configured to enforce a “clear-then-post” discipline. The receipt voucher entry screen should require the user to select the customer, which then populates a list of all open invoices. The system should provide automated matching suggestions based on payment amount, invoice numbers embedded in reference fields, or other identifiers. For payments that don’t perfectly match, the ERP should facilitate partial payment application. Posting a payment “on-account” should be an exception, requiring a specific reason code and potentially a higher level of approval. The system workflow should prevent the voucher from being finalized until at least a specified percentage of the receipt amount has been allocated.

Governance & Control: A key control is to introduce a policy that no receipt can be posted “on-account” without documented approval from the Finance Manager. A weekly “Unapplied Cash Report” should be automatically generated by the ERP and reviewed by the AR Supervisor and Controller. The primary KPI here is the “Percentage of Total AR Represented by Unapplied Cash,” which should be maintained below a minimal threshold (e.g., less than 1%). Segregation of duties is also critical: the individual who posts the receipt voucher should not be the same person who can approve large “on-account” postings or write-offs.

Problem 2: Late Posting and Ignoring Actual Value Date

Problem: A significant discrepancy often arises between three key dates in the receipt process: the Document Date (when the voucher is created in the ERP), the Posting Date (the accounting date that affects the general ledger), and the Value Date (the date the funds are actually received and available for use in the company’s bank account). The problem occurs when teams post receipts with incorrect dates, typically using the entry date as the posting and value date, or when there is a significant lag between receiving the funds and posting the transaction in the ERP.

Root Causes: This is often a procedural failure driven by workload pressures or lack of discipline. The AR team may accumulate receipts and post them in batches every few days, rather than daily. For bank transfers, particularly international ones, the team may post the receipt based on the customer’s remittance advice rather than waiting for the funds to appear in the bank statement, thus ignoring the true value date. ERP systems not configured to enforce the use of a separate “Value Date” field for cash and bank-related transactions exacerbate this issue.

Impact: The financial impact is multi-faceted. Firstly, it renders cash flow forecasting and daily cash position reporting inaccurate. The treasury department may believe it has less (or more) liquidity than it actually does. Secondly, for foreign currency receipts, using the wrong value date leads to incorrect calculation of realized foreign exchange gains or losses, as the exchange rate on the value date is the one that should be used per IFRS/SOCPA standards. Thirdly, it makes bank reconciliation extremely difficult, as the dates in the ERP’s cash book will not align with the dates on the bank statement, requiring manual matching and investigation.

Solution: The ERP must be configured with a clear and mandatory distinction between Posting Date and Value Date on the receipt voucher screen. The Posting Date should drive the AR sub-ledger entry (crediting the customer), while the Value Date must drive the general ledger entry to the bank account. This ensures that the ERP’s bank ledger accurately reflects the bank’s own records. The internal process must mandate daily posting of all receipts. For bank transfers, the ironclad rule should be: do not post the receipt voucher until the credit is confirmed on the electronic bank statement. The ERP can assist by automatically importing bank statements and flagging incoming payments for processing.

Governance & Control: The primary control is a “T+1” posting policy: all receipts confirmed on Day T must be posted in the ERP by the end of Day T+1. The performance of the AR team should be measured by their adherence to this policy. The month-end closing checklist must include a validation step to ensure no un-posted receipts exist and that the value dates for all receipts in the last few days of the month are correct. The Treasury department should be a key stakeholder, as the accuracy of the value date directly impacts their operations.

Problem 3: Mixing Payment Methods (Cash/Cheque/Transfer/POS) in One Voucher

Problem: In an attempt to simplify data entry, AR clerks sometimes create a single receipt voucher to record a payment that was received via multiple methods. For example, a customer might settle a large invoice with a portion paid by bank transfer, a portion by cheque, and the remainder via a Point-of-Sale (POS) terminal. Consolidating these into one voucher in the ERP is a critical error that destroys the audit trail and complicates reconciliation.

Root Causes: The primary cause is a misunderstanding of the “one-to-one” principle of financial transaction tracing. It can be perceived as more efficient to clear a single invoice with a single receipt voucher, regardless of how the funds were tendered. This is compounded by ERP configurations that are too flexible, allowing a user to create a complex journal entry within the receipt module that debits multiple cash/bank accounts against a single customer credit. A lack of clear procedural guidelines from finance leadership is also a significant contributing factor.

Impact: The main impact is the breakdown of reconciliation. A single voucher hitting three different payment sources makes it impossible to perform an automated or even a simple manual reconciliation. The bank reconciliation module cannot match a portion of a voucher to a line on the bank statement. The POS settlement report from the acquiring bank cannot be matched to a partial amount within a larger ERP voucher. Similarly, the cash deposit slip for the cash portion cannot be easily tied back. This forces the accounting team into time-consuming manual analysis, increases the risk of un-reconciled items, and can hide issues like cash leakage or un-deposited cheques.

Solution: The solution is structural and must be enforced by both process and ERP configuration. The cardinal rule is: **One payment instrument, one receipt voucher.** A payment received via three methods must be recorded using three separate receipt vouchers. 1. A voucher for the bank transfer, with the bank’s transaction reference number in a dedicated field. 2. A voucher for the cheque, with the cheque number and bank details recorded. 3. A voucher for the POS payment, with the transaction or batch ID from the POS terminal. Each voucher would be applied as a partial payment against the same invoice. The ERP should be configured with different “Payment Method” types (e.g., ‘Bank Transfer-SAR’, ‘Cheque-AlRajhi’, ‘POS-Visa’), each linked to a specific interim or final clearing GL account. This segregation is non-negotiable for control and traceability.

Governance & Control: The finance policy manual must explicitly forbid the mixing of payment methods in a single receipt voucher. The ERP user roles and permissions should be designed to guide users into the correct, segregated data entry process. Internal audit should periodically test for this specific issue by sampling receipt vouchers and tracing them back to their source documentation and bank statements. The KPI is straightforward: the “Percentage of multi-method vouchers” should be zero.

Problem 4: Missing Reconciliation With Bank Statement and POS

Problem: Many organizations diligently post receipt vouchers in their ERP but fail to perform the final, crucial step: systematically reconciling these internal records against external, third-party statements. This includes matching ERP bank receipt entries against the company’s official bank statements and matching ERP POS receipt entries against the settlement reports from the merchant acquirer (the bank processing the card payments). Without this reconciliation, there is no independent verification that the money recorded in the ERP has actually been received.

Root Causes: This neglect often stems from a historical reliance on manual processes, which are so time-consuming that reconciliation is done infrequently or not at all. There may be a lack of expertise in using the ERP’s automated bank reconciliation module. Another cause is the data integrity issue discussed in previous points—if payment methods are mixed, value dates are wrong, or reference numbers are missing, automated reconciliation becomes impossible, discouraging the team from even attempting it.

Impact: The absence of reconciliation is a catastrophic failure of internal control. It can conceal a wide range of problems: bank errors, excessive bank charges, fraud (e.g., an employee pocketing cash and posting a fake receipt), bounced cheques that were never reversed, or POS transactions that failed to settle. It leads to an inaccurate cash balance in the financial statements and provides a false sense of security. At month-end, the finance team is faced with an impossible task of explaining the difference between the ERP’s book balance and the bank’s statement balance, often resorting to a “plug” figure, which is a major red flag for auditors.

Solution: The solution lies in the disciplined use of the ERP’s Bank Reconciliation and Treasury modules. The process should be: 1. **Automated Import:** Configure the ERP to automatically import electronic bank statements daily (e.g., in MT940 or CAMT formats). The same should be done for POS settlement reports. 2. **Automated Matching:** The system should be set up with rules to automatically match ERP transactions with bank statement lines. Matching criteria can include: Amount, Value Date, and Reference Number (e.g., cheque number, transfer ID). A high percentage (e.g., 85-95%) of receipts should be matched automatically. 3. **Exception Handling:** The ERP should present a clear user interface for the accountant to manually investigate and match the few remaining items. This is where human judgment is needed to resolve discrepancies. 4. **Closure and Reporting:** Once reconciled, the statement period is closed in the system, and a formal reconciliation report is generated, which serves as key audit evidence. This process should be performed, at a minimum, on a weekly basis, though daily is best practice.

Governance & Control: Bank reconciliation is a classic detective control and a prime area for segregation of duties. The person posting customer receipts should not be the one performing the bank reconciliation. The reconciliation report must be reviewed and signed off by the Financial Controller monthly. The number of aging, un-reconciled items is a critical a KPI that must be tracked and kept to a minimum. Any un-reconciled item older than a set number of days must be escalated for investigation.

Problem 5: Incorrect Treatment of Early-Settlement Discounts and Commissions

Problem: Customers often pay an amount net of certain deductions, such as an early-settlement discount or bank/payment gateway commissions. A common error is for the AR clerk to either leave the small balance of the discount on the invoice as an open amount or to incorrectly write it off to a generic “bad debt” or “sundry expense” account. This misrepresents the nature of the transaction and clutters the AR ledger.

Root Causes: The issue originates from a lack of clarity in accounting policy and inadequate ERP configuration. The AR team may not be trained on the correct accounting treatment for different types of deductions. The ERP’s receipt voucher screen might not have a simple mechanism to handle these “payment differences.” Forcing the clerk to post the net amount received and then separately create a credit note is often seen as too cumbersome, leading to shortcuts and errors.

Impact: Leaving small balances on invoices creates “noise” in the AR aging report, requiring manual clean-up and write-offs at month-end. It also means the customer’s statement of account is perpetually incorrect. More seriously, misclassifying these deductions has a direct impact on the P&L. An early settlement discount should, under IFRS 15, be treated as variable consideration, reducing revenue. Bank charges or POS commissions are operating expenses. Lumping them into a miscellaneous account or, worse, bad debt expense, distorts gross margin analysis and performance measurement.

Solution: A modern ERP provides an elegant solution through “Reason Codes” within the cash application/receipt voucher module. When applying a payment that is less than the invoice amount, the system should prompt the user to account for the difference. The user can then select a pre-defined reason code, such as: – `ESD`: Early Settlement Discount – `BC`: Bank Charges – `POS_FEE`: POS Commission – `FXD`: FX Difference Each reason code is pre-configured to post the difference to a specific General Ledger account. For example, `ESD` would post to a “Sales Discounts” contra-revenue account, while `BC` would post to “Bank & Financial Charges.” This allows the AR clerk to clear the full invoice amount and correctly account for the deduction in a single, efficient step. The system should also be able to validate discount eligibility based on the payment terms and dates.

Governance & Control: The Finance department must define and approve the list of reason codes and their corresponding GL account mappings. Tolerances can be set within the ERP, allowing clerks to automatically write off differences up to a small, pre-defined limit. Larger differences would require supervisor approval within the ERP workflow. A monthly report analyzing all “payment differences by reason code” should be reviewed by the Controller to monitor trends in discounts and bank charges.

Problem 6: No Linkage to VAT and the E-Invoice

Problem: In the context of the Kingdom of Saudi Arabia’s Zakat, Tax and Customs Authority (ZATCA) e-invoicing framework, any transaction that modifies the financial value of a cleared tax invoice must itself be a compliant electronic document (a credit or debit note). A frequent oversight is when a payment discrepancy (e.g., a short payment accepted as full settlement due to a quality dispute) is handled informally within the AR ledger without generating a ZATCA-compliant credit note. This creates a mismatch between the company’s VAT filings and ZATCA’s records.

Root Causes: This is a process gap resulting from a failure to fully integrate commercial settlement processes with tax compliance obligations. The AR team may view their role as simply “clearing the cash,” not as an actor in the VAT reporting chain. The ERP system’s receipt voucher workflow may not be integrated with its credit note generation and ZATCA B2B clearance/B2C reporting module. If creating a compliant credit note is a separate, manual process, it is likely to be skipped for the sake of speed.

Impact: The primary impact is tax compliance risk. If a company allows a customer to short-pay an invoice and writes off the balance without issuing a corresponding e-credit note, the company’s reported revenue and output VAT will be higher than what was economically realized. ZATCA’s systems will show an invoice for a higher amount, while the company’s books reflect a lower receipt. This discrepancy can trigger audits, penalties, and requires complex reconciliations. It fundamentally breaks the data integrity chain that e-invoicing is designed to create.

Solution: The ERP workflow must be redesigned to link payment application with tax compliance. When a receipt is applied and there’s a remaining balance that needs to be written off for reasons other than a standard bank fee (e.g., goods returned, post-invoice discount, dispute settlement), the “reason code” selected by the AR clerk must trigger an automated workflow. 1. The user selects a reason code like “Customer Quality Rebate.” 2. The ERP flags this as requiring a tax-relevant adjustment. 3. The system automatically drafts a credit note, pre-populating it with data from the original invoice (including its unique identifier/UUID as required by ZATCA) and the write-off amount. 4. This draft credit note is routed for commercial approval (e.g., to the Sales Manager). 5. Upon approval, the ERP finalizes the credit note, submits it to the ZATCA platform for clearance (for B2B), and posts the associated accounting entries, simultaneously clearing the remaining balance on the original invoice. This integrated process ensures that every financial settlement is perfectly mirrored by a compliant tax document.

Governance & Control: The Chief Financial Officer and Tax Manager are ultimately responsible for ensuring this linkage. The configuration of reason codes and their link to the credit note workflow is a critical IT governance control. The internal audit plan must include testing of this specific end-to-end process: sample invoices with partial payments and write-offs and verify that a corresponding, ZATCA-compliant credit note exists and is linked to the original invoice in the ERP.

Problem 7: Weak Control Over Incoming and Post-Dated Cheques

Problem: The management of physical cheques, particularly post-dated cheques (PDCs), is a high-risk area. A common and serious accounting error is to treat PDCs as cash upon receipt. This means debiting the bank account and crediting the customer before the cheque’s due date, which violates IFRS principles (a PDC is a financial instrument, a promise to pay, not cash). Operationally, weak controls can lead to misplaced cheques, failure to present them on the due date, or inability to track them effectively.

Root Causes: The incorrect accounting treatment often comes from legacy practices or a lack of understanding of IFRS 9. Operationally, the absence of a dedicated PDC management module in the ERP forces teams to use insecure, manual methods like spreadsheets or physical diaries to track due dates. This manual process is prone to human error and lacks transparency and auditability. The ERP may not be configured to handle the specific lifecycle of a cheque: receipt, safekeeping, presentation, and clearance/bouncing.

Impact: Accounting for PDCs as cash prematurely overstates the company’s liquidity and cash position, providing a misleading picture to management and stakeholders. It also understates the customer’s true outstanding balance, potentially leading to the extension of further credit beyond approved limits. From an operational standpoint, poor physical and system controls can lead to direct financial loss through lost cheques or failure to deposit them on time. It also complicates the tracking of bounced cheques and the subsequent follow-up process, delaying cash collection.

Solution: A best-in-class ERP must have a dedicated Post-Dated Cheque Management module. The correct, IFRS-compliant process is as follows: 1. **PDC Receipt:** Upon receiving a PDC, a special “PDC registration” transaction is posted. This entry is a “noted item” or “statistical posting.” It does *not* hit the main bank GL account. Instead, it credits the customer’s AR account (to show the invoice is covered by a PDC) and debits a special “Cheques Under Collection” control account. The cheque’s details (number, date, due date, bank) are captured. 2. **Safekeeping & Reporting:** The physical cheque is stored securely. The ERP can generate reports of all PDCs held, sorted by due date, customer, etc. 3. **Due Date Alert:** The ERP should automatically alert the treasury or AR team a few days before a PDC’s due date. 4. **PDC Presentation:** On the due date, the team presents the cheque to the bank. A transaction is posted in the ERP to move the amount from “Cheques Under Collection” to “Cheques Presented but Not Cleared.” 5. **Clearance/Bounce:** When the bank statement confirms the cheque has cleared, a final transaction is posted: debit the actual Bank GL account and credit “Cheques Presented but Not Cleared.” If it bounces, a reversal process is initiated, which re-opens the customer invoice and flags the account for follow-up.

Governance & Control: Strict dual-control policies must be in place for the physical custody of cheques. The PDC Management module in the ERP provides the system-based control and audit trail. Access to this module should be restricted. A monthly reconciliation must be performed between the physical cheques held in the safe and the “Cheques Under Collection” balance in the ERP. The Treasury department owns this process, ensuring that liquidity forecasts correctly exclude the value of PDCs.

12-Week Implementation Plan

85/15 Matrix: Automation vs Human Judgment

Key Performance Indicators

• Days Sales Outstanding (DSO): The ultimate measure of collection efficiency. A well-managed receipt process directly contributes to lowering DSO by ensuring payments are applied promptly and correctly. Target should be a continuous downward trend or alignment with industry benchmarks.
• Percentage of Unapplied Cash: This KPI measures the value of cash received but not allocated to specific invoices, as a percentage of total AR. A high-performing organization should maintain this below 1-2%.
• Auto-Reconciliation Rate: The percentage of bank statement lines that are matched automatically by the ERP without any human intervention. A best-in-class process aims for a rate above 90-95%.
• Average Time to Apply Cash: The average time (in hours or days) from when a payment appears on the bank statement (value date) to when it is fully applied in the ERP. The target should be less than 24 hours (T+1).
• Number of Reconciling Items Aged > 15 Days: Tracks the number of items that remain unmatched during bank reconciliation for more than 15 days. This number should be trending towards zero.
• PDC Bounce Rate: The value of bounced post-dated cheques as a percentage of the total value of PDCs presented in a period. This is a key indicator of customer credit quality and risk.

Frequently Asked Questions

Ultimately, executive leadership must recognize that the receipt voucher is more than an accounting formality; it is the definitive record of value realization. By systematically addressing the deep-seated procedural and system-level problems within the receipt-to-reconciliation cycle, an organization does more than just clean up its books. It builds a foundation of financial integrity, enhances its operational agility, strengthens governance, and unlocks the real-time, trustworthy data needed to navigate the complexities of the modern Saudi economy with confidence and strategic foresight.