Cash application explains which customer payment belongs to which open invoice. Collection forecasting estimates when still-open invoices may become cash. They are connected controls, but they answer different questions and should not share one ambiguous status field.

Stripe's payment-application documentation distinguishes applying, unapplying, and reapplying payments to invoices. Microsoft's cash-flow forecasting documentation describes forward-looking cash timing inputs such as payment terms and the delay between due and payment dates. The practical boundary is simple: application reconciles an observed payment; forecasting makes a dated assumption about a future receipt.

Keep two ledgers of meaning

| Question | Cash application | Collection forecast | | --- | --- | --- | | Primary object | Observed payment and invoice linkage | Open invoice and expected receipt timing | | Main evidence | Payment ID, amount, date, remittance, application | Current promise, approval, dispute, history, owner | | Completion state | Payment is tied to the correct invoice balance | Outcome is compared with the locked assumption | | Main failure | Cash is unmatched, misapplied, or duplicated | Timing is unsupported, stale, or overconfident |

An applied payment can reduce or close an invoice without explaining when funds become available in the bank. A forecasted invoice can have a strong expected week even though no payment exists yet. Preserve both states.

Reconcile actual cash before updating the open balance

When a payment arrives, record the source reference and receipt date, then match it to the supported invoice or invoices. If the link is uncertain, keep the payment in an application exception instead of guessing from amount alone. The unmatched payment guide gives that exception a bounded owner and review path.

Once the application is supported, reduce the corresponding invoice balance. If the payment covers several invoices, allocate only the observed amounts. Do not retain the full original invoices and also count the receipt as a separate forecast inflow.

Forecast the remaining population

After application, the forecast begins with the current open invoice population. For each material row, preserve source amount, due date, evidence, expected week or unassigned state, owner, and review date. The four-week cash forecast guide explains how that decision layer differs from the accounting source.

Use this event sequence:

  1. Lock the forecast snapshot.
  2. Observe a payment or settlement event.
  3. Apply the supported amount to the correct invoice balance.
  4. Move observed cash to actuals under the defined cutoff.
  5. Reforecast only the verified residual and preserve the prior assumption for variance review.

Avoid three common mix-ups

  • Do not call a predicted receipt an unapplied payment; no payment exists yet.
  • Do not assign an unmatched receipt to the most convenient invoice without evidence.
  • Do not treat application date, deposit date, and forecast week as interchangeable.

The invoice payment-date versus deposit-date guide separates accounting application from bank timing. The forecast reconciliation bridge preserves the path from locked expectation to observed receipt and residual.

AR Pulse works from an authorized QuickBooks receivables export to create an invoice-level cash-action list and four-week range. It does not apply payments, change accounting records, or contact customers. Apply for AR Pulse when the open-invoice forecast needs a traceable decision layer.