On the Receipts Allocate screen, users can't always allocate a historical receipt to the invoice it belongs against. Sometimes no outstanding invoices show up at all; other times the screen's filters are hiding invoices that are actually there. Either way the user is stuck.
The workaround people fall back on is re-keying the receipt, which creates a duplicate and makes a mess of the ledger. So the current gap isn't just an inconvenience, it's actively pushing users towards a bad outcome.
Objective
Let users find and allocate a historical receipt against the correct invoice from the Receipts Allocate screen, without creating a duplicate receipt and without posting incorrectly to the ledger.
In scope
Allocating receipts dated in prior periods to invoices on the Receipts Allocate screen
Fixing or relaxing the filters so genuinely allocatable invoices are visible
Making it clear on screen when nothing is returned and why
Preventing duplicate receipts arising from the workaround
Out of scope
Changing how receipts are created or imported
Reopening closed accounting periods
Any change to allocation logic itself once the correct invoice is selected
Functional requirements
Diagnose the two failure modes separately. These look the same to the user but need different fixes:
Filter problem: the invoice exists and is allocatable, but the screen's default filters (date range, status, entity, period) exclude it. Fix is to widen or expose the filters.
Data problem: there genuinely is no matching outstanding invoice, because it's already fully allocated, was written off, sits under a different entity, or was never raised. Fix is to tell the user that clearly rather than showing an empty list.
Filters. Filters on the screen should be visible and adjustable, with the current filter state shown so users can see what's being excluded. A way to search across all invoices for the account, ignoring date defaults, would cover most of the reported cases.
Empty state. When no invoices are returned, the screen says why — "no outstanding invoices for this account", "3 invoices excluded by date filter", and so on. Silent empty results are what drives the re-keying workaround.
No duplication. The original receipt is allocated, not copied. Allocation doesn't create a second receipt record under any path through this screen.
Ledger correctness. Allocating a historical receipt moves it from unallocated to allocated against the invoice. It shouldn't create a new cash posting, change the receipt's original date or value, or restate a closed period. Where the receipt sits in a closed period, the allocation needs to post per whatever the agreed accounting treatment is, which is an open question below.
Permissions. Allocating across periods should be limited to appropriate roles, since it has accounting consequences.
Validation and audit
Standard Catch-e confirmation prompts before committing an allocation
Full audit trail: receipt, invoice, amount, user, date, and the period the allocation was posted to
Allocations remain reversible, with the reversal audited the same way
The system blocks allocating more than the receipt's remaining unallocated balance
Acceptance criteria
A user can locate and allocate a historical receipt to its invoice from the Receipts Allocate screen
Where invoices are hidden by filters, the user can see and adjust those filters
Where no invoice genuinely exists, the screen says so explicitly
No duplicate receipt is created by any path
The ledger reflects the allocation correctly, with no double-counting of cash and no unintended restatement
The whole thing is audited and reversible