When one customer payment covers several invoices, allocate the recorded receipt to the supported invoice rows before updating the AR forecast. Cash has been received once; the remaining open balances must change invoice by invoice. Until the allocation is traceable, keep the affected rows out of confident weekly collection totals rather than guessing which invoices were settled.

Microsoft's settlement overview explains that customer payments can be posted before or with settlement and that the correct transactions are marked when the payment is applied. J.P. Morgan's cash-application guide describes cash application as matching incoming payments to customer accounts and invoices, including cases where remittance detail and funds arrive at different times. Intuit also notes that customers may pay multiple due invoices together. The forecast therefore needs a receipt-to-invoice bridge, not a customer-level subtraction.

Preserve the receipt as one event

Start with the recorded receipt facts:

  • customer and paying entity;
  • receipt date and amount;
  • bank or processor reference;
  • remittance reference or message;
  • currency and entity;
  • source-system payment identifier.

Do not duplicate the receipt across invoice rows. The payment amount is a control total that the invoice allocations must reconcile back to.

Build an allocation table

Create one row for every candidate invoice and preserve the original invoice number, due date, and open balance. Add an allocated amount, allocation evidence, and exception status. The sum of allocated amounts must equal the portion of the receipt that is actually supported.

Use this sequence:

  1. Match explicit invoice references in the remittance detail.
  2. Confirm the customer, entity, currency, and AR account align.
  3. Check that no allocation exceeds the invoice's open balance.
  4. Separate discounts, credits, short pays, fees, or overpayments instead of forcing them into an invoice allocation.
  5. Leave any unsupported remainder as unapplied or unresolved according to the source-system process.
  6. Preserve the preparer, reviewer, and allocation timestamp.

This table provides information gain beyond a customer-level aging total: it shows exactly how one cash event changed several forecast rows.

If the shared event is a customer credit rather than a payment, use the multi-invoice credit memo bridge. A credit reduces supported receivables but is not an observed cash receipt.

Update the forecast without counting cash twice

For each settled invoice, reduce the open balance by the supported allocation. If the remaining balance is zero, remove that invoice from future expected-receipt weeks. If a residual remains, forecast only that residual and reassess its evidence. Never leave the full invoice amount in a future week after part of the receipt has already been recorded.

If the payment arrived after the forecast cutoff, keep the locked prior forecast unchanged and record the receipt as an observed outcome in the next variance review. The partial-payment guide handles invoice residuals, while the cash-receipt cutoff guide separates prior actuals from later postings.

Stop conditions

Do not finalize the allocation when the paying entity does not match, the remittance is missing, the receipt total does not reconcile, the same amount appears applied twice, or an unexplained credit remains. Assign the exception to a named internal owner and set the next review date.

AR Pulse works from an authorized QuickBooks receivables export to create an invoice-level action list and four-week collections view. It does not move cash or post payment applications. Finance teams that want a source-linked review can apply for AR Pulse.