August 2026 / Manual match
Draft run · not closedPrototype v0.2 · real August data, masked
For: HQ finance officer · J8
Can this payment be matched to another branch?
Manual reconciliation: search across branches, record a reason, an explanation and evidence, and send it for approval. The candidate branch sale is an example, since August has one branch's POS data.
Decisions this view supportsWho may match across branches · Who approves (maker-checker)
Payment with no match in its branch
Automated matching stopped at the branch boundary. A person can look further.
- Payment
- M-Pesa …TT24 · KES 6,000 · 29 Aug 17:20
- Received by
- Hurlingham POS
- Hurlingham match
- None within 15 minutes
Search other branches (manual only)
Amount 6,000, ±1 day · all branches
| Branch | POS sale | Amount | Time |
|---|---|---|---|
| KFC Southfield Mall example | …40217 | KES 6,000 | 29 Aug 17:20 |
Record the reason
The reason list is managed in Settings; no code change needed.
Reconciliation reason (required)
Explanation (required)
e.g. Customer paid the Hurlingham M-Pesa till number while collecting at Southfield Mall; confirmed by both store managers.
Supporting attachment (optional)
Receipt, credit note, return form, delivery note or payment confirmation (PDF or image, up to 10 MB)
Submit for approvalCross-branch: the finance manager approves before it posts
What the audit trail keeps
Every manual and cross-branch action, in full, never edited.
| Field | Recorded |
|---|---|
| Payment reference | M-Pesa …TT24 |
| Original allocation | Hurlingham · missing POS |
| New allocation | KFC Southfield Mall · POS sale …40217 example |
| Source and destination branch | Hurlingham → KFC Southfield Mall |
| Reason and explanation | Wrong branch allocation · the text above |
| Attachment | file name and fingerprint, if added |
| Submitted by / approved by | Finance officer / finance manager, each with date and time |
| Ledger | Void in Hurlingham, repost in Southfield Mall, linked to this record |
Built from the pipeline run of 10 Oct 2026 (Payments.xlsx + POS export). Customer details are masked and cashiers are shown as pseudonyms. Items tagged "assumed" rest on assumptions in the spec.