Review payment details and allocation history
Where: Payments → select the generated payment number.
Who: payment.view and business-unit access.
The detail shows the receipt itself, its allocation balances and the invoice allocation table. Read all three; a status label alone does not establish which customer bill was settled.
Receipt fields
| Field | What to verify | Example |
|---|---|---|
| Payment number / type / status | Right receipt and current lifecycle | PAY-…, Customer payment, Posted |
| Payment date | Actual business date of receipt | 08/11/2026 |
| Method / reference | Matches payment evidence | Bank transfer / FPS-77812 |
| Business unit ID | Correct owner | 3 |
| Customer partner ID | Correct trading relationship | 42 |
| Amount | Original receipt in transaction currency | 200.0000 GBP |
| Base amount | Saved rate conversion | 200.0000 GBP at rate 1 |
| Allocated | Amount already applied to invoices | 150.0000 GBP |
| Available | Unallocated amount | 50.0000 GBP |
| Exchange rate / date | Recorded conversion context | 1.00000000 / 08/11/2026 |
| Posted | Posting time and recorded actor, if present | Empty before posting |
| Created / Updated | Record audit context | Read with transaction references |
| Notes | Relevant reconciliation detail | First instalment |
Amounts display four decimal places and rates eight. A dash is an absent field, not a zero amount or assumed rate date.
Allocation table
| Column | Meaning |
|---|---|
| Invoice ID | Numeric target sales invoice ID, not printed number |
| Amount | Transaction-currency amount applied by this allocation |
| Base amount | Allocation converted using this receipt's saved rate |
| Notes | Allocation-specific context |
| Created | Allocation audit time/actor |
No allocations means the loaded receipt has no recorded allocation rows. It can be a perfectly valid Posted advance still waiting for a bill. It is not proof the customer has not paid.
The generic detail does not turn Invoice ID or allocation ID into a journal link. Use Sales invoices and the relevant order/accounting view to trace the target bill and journal.
Example: one receipt, two allocations
| Receipt | Original amount | Allocations | Available |
|---|---|---|---|
PAY-A | 500 | Invoice 501: 327.60; invoice 502: 100 | 72.40 |
The payment is Partially allocated. Invoice 501 might be Paid while invoice 502 might still be due more. Open each bill to check its complete history, including allocations from other receipts and effective credits.
Review before posting
Farah or Nadia checks:
- Evidence refers to one actual receipt and it has not already been entered through Sales.
- Customer Partner and business unit match the intended account.
- Amount, currency, method and receipt date match evidence.
- Base currency/rate are approved and stored correctly.
- Notes/reference allow the team to find the event later.
There is no Edit receipt button. For an incorrect Draft, use Cancel and correct; for a Posted error, involve Accounts before recording anything else.
Refreshing after errors
The detail may show Reload payment details before another action. The last request may have completed. The component can refresh automatically after an action error. If refreshed data is not available, reload the browser page or return to Payments and reopen the receipt.
There is no visible Reload button on the current payment detail header. Do not confuse the invoice detail's Reload control with this page. Check the returned status and allocations before retrying a write.