Understand partial payments and recorded balances
Employee reimbursement supports multiple recorded payments. The counter tracks amounts recorded at creation, not only POSTED or bank-settled payments.
Numerical example
| Step for a GBP 300 expense | Recorded now | Amount Paid | Amount Due | Expense state |
|---|---|---|---|---|
| Initial posted expense | 0 | 0 | 300 | POSTED |
| First payment created | 100 | 100 | 200 | PARTIALLY_PAID |
| Second payment created | 75 | 175 | 125 | PARTIALLY_PAID |
| Final payment created | 125 | 300 | 0 | PAID |
Each newly created payment begins IN_PROCESS. The expense can reach PAID before any row is validated to POSTED. A partially-paid label is about the counter, not necessarily a partially completed bank settlement.
Verify after every record
Read the full newest-first payment list, actual states and recorded amounts. Compare to the stored counters and approved external payment evidence. Use the list endpoint/UI rather than a legacy single-payment lookup, which returns only the latest related payment under the journal.
The journal-only relationship created during posting has no payment ID and is excluded from payment history. It is not a zero-value payment.
Cancellation/reset effect
The reviewed cancel/reset/confirm/validate wrappers do not recalculate expense Amount Paid, Amount Due or expense state. If the GBP 100 record above is cancelled, do not assume due becomes 300 again. The stored counters can remain 100/200 even though that row is CANCELLED.
Do not create a replacement payment until finance/support establishes the correct remaining obligation and supported correction. Manually changing state, resetting/revalidating or adding another record can compound the inconsistency; there is no automatic balance rebuild action here.
Company-paid difference
Company posting creates one full payment and sets PAID without the same counter-update code. Older migration backfills may also reflect historical statuses differently from newly created company records. Read actual payment/expense facts; do not infer a reliable settled balance from the label alone.
Overpayment against current stored due is rejected sequentially, but the source does not expose a complete concurrency/idempotency protocol for two simultaneous creators. Coordinate recording and verify the latest saved list before another payment.