An invoice due date and its expected collection date should remain separate because they answer different questions. The due date records when payment is contractually due. The expected collection date is a dated management assumption about when cash may arrive, supported by current evidence. Copying every due date into a four-week forecast hides uncertainty and turns the forecast into another aging report.
Intuit's reminder documentation uses invoice due dates to determine when an invoice is soon due or overdue. Oracle's promise-to-pay documentation treats a customer's commitment as a separate record with its own amount and date. Those facts belong beside each other: the due date establishes status; newer evidence can support a different forecast week without rewriting the invoice.
Keep three dates visible
Every invoice-level forecast row should preserve at least:
- **invoice date:** when the invoice was issued;
- **due date:** when payment is due under the recorded terms;
- **expected collection date or week:** the current cash-timing assumption.
Add the forecast snapshot date and the date of the evidence supporting the assumption. A reviewer should be able to tell what was known when the forecast was prepared.
Do not let due status choose the cash week automatically
An invoice can be current yet supported for Week 1 by a dated payment commitment. Another can be overdue but remain unconfirmed because approval, dispute, payment application, or follow-up evidence is missing. A third can have a due date inside Week 2 but no evidence beyond the original terms.
Use a routing rule rather than a silent copy:
- Preserve the due date unchanged.
- Review current invoice status and source evidence.
- Assign an expected week only when the evidence supports it.
- Label the assumption supported, conditional, unconfirmed, or blocked.
- Record the internal owner, next action, and review date.
- Keep later and unconfirmed rows outside confident weekly totals.
The expected date is not a new accounting fact. It is a reviewable planning field.
For project-based billing, the accounting-date comparison adds a fourth date and shows why a ledger period should not choose the cash week.
When the two dates should differ
A difference can be reasonable when a dated promise changes timing, an approval or dispute blocks payment, a receipt is in transit but not yet recorded, or observed evidence contradicts the original terms. The reason must be explicit. Avoid using a generic customer habit as if it were proof for every invoice.
The promise-to-pay framework shows how to preserve commitments, while the due-date-versus-invoice-date diagnostic explains why aging status must use a clear date basis.
Use variance review to improve the assumption
Lock the forecast before actual receipts arrive. Later, compare the expected week with the recorded receipt date and classify the variance: timing changed, evidence was weak, invoice status changed, or cash application lagged. Do not rewrite the old expected date to match hindsight.
This creates a useful feedback loop without inventing payment probabilities. The forecast variance review provides the comparison structure.
AR Pulse converts an authorized QuickBooks receivables export into a ranked cash-action list and a four-week collections forecast. It does not contact customers or promise payment outcomes. Finance owners who need a source-linked forecast can apply for AR Pulse.