Prototype · October 2026
Pakistan Post: reconciliation that finds the money, names who owns it, and proves the fix.
The published audit of the postal sector describes balances that should have been reconciled and were not — money orders left unadjusted, cash held above limits, receivables nobody chased. The ledger, the bank and the money order register already hold the answers. What is missing is the layer that compares them every night, turns what does not add up into a short ranked list of cases, puts each in front of a named officer on a clock, and records what was decided. This is a working prototype of that layer. The data is fictional and it runs in your browser; the guided run performs every step for real as it explains it.
The gap
The money is in the systems. The reconciliation is not.
The Auditor-General’s report on the postal sector for 2024–25, as reported in July 2026, puts the operational deficit at Rs 19.32 bn and flags irregularities of about Rs 63 bn, including Rs 7.29 bn of inland money orders left unadjusted and Rs 11.28 bn of cash held without justification. The figures cover the postal sector and Postal Life Insurance together, so not all of it is Pakistan Post — but the pattern is the point: balances that should have been reconciled were not, and nobody was made to look until the audit did.
Periodic reporting finds these things months later, in aggregate. A control finds them the morning after, one at a time, with a name against each. That is the difference between an audit observation and a recovered balance.
Nothing needs replacing. Pakistan Post’s own annual report describes delivery-tracking apps and a push to motorise last-mile delivery; the operational systems are moving. The financial control layer across the ledger, the bank, money orders and settlements is the piece with the most money behind it and the clearest way to measure success.
The loop
Predictive, prescriptive, closed-loop, auditable.
A system that only reports an unusual balance is useful. One that matches it to the records, explains it, gives it to the right officer, tracks it to resolution and measures what was recovered is a control.
Five solutions
Five places AI could help, and the one to start with.
Five ways AI could help Pakistan Post. The first is the pilot worth starting with, because the problem is documented by the audit and the result is countable in rupees and staff hours — it is the one this prototype implements.
| Solution | What it does |
|---|---|
| Postal financial intelligencepilot first · in the demo | Continuous reconciliation of bank, ledger, money orders, advances and inter-office accounts; exceptions ranked by exposure and tracked to resolution. |
| Network control tower | Predicts which parcels will be late, finds bottlenecks at sorting and exchange offices, and recommends the next operational move. |
| E-commerce growth platform | Merchant booking, pickup, proof of delivery and cash-on-delivery settlement that reconciles itself, with failed-delivery analysis. |
| Branch profitability and assets | Cost-to-serve by branch, route and service, kept separate from the universal-service obligation so rural access is not traded away. |
| Voice and complaint intelligence | Urdu-first tracking and complaints over voice and messaging, with complaints turned into patterns by office and route. |
What it adds
An exception engine, not another dashboard.
What has to sit on top of the existing systems for a problem to stop going quiet.
Predictive.
Thousands of ledger lines go into the overnight match against the bank, the money order register and the COD settlements, and almost all of them match on their own. What is left is a short list of cases, ranked by money at stake multiplied by how likely the engine thinks the problem is real — not by date received.
Explained, not asserted.
Every case shows the evidence side by side, source by source, and the signals behind the score with their weights. The weights add up to the likelihood, so nobody has to take the number on trust and an officer can disagree with any line of it.
Prescriptive.
Each case carries a specific next action — get these 37 vouchers from that office, adjust what is vouched, recover the rest — rather than “unusual activity detected”. That is the difference between a report and a control.
Closed-loop.
A named officer holds every open case on a clock set by severity. Waiting on another office is recorded with who, what and when it is expected. Past the deadline, the Divisional Head hears about it automatically.
A person decides.
The engine never posts, reverses or writes off an entry, and never recovers money. A resolution at or above the approval limit needs the Divisional Head’s signature, whatever the score.
It learns from being wrong.
A false alarm needs a reason, and the reasons are counted by kind. Raising the confidence threshold shows, before anyone relies on it, exactly which suspicions would drop out of the queue — including the ones that were probably real.
Auditable by construction.
Every step writes an append-only line: what the engine recommended, what the officer decided, who approved it and what followed. Internal Audit sees everything and can change nothing.
The guided run
It explains itself, by doing it.
Eighteen steps: the overnight match raises a Rs 2.84 m money-order case at GPO Multan; the Accounts Officer takes it, asks for the vouchers, gets 31 of 37 back and records an adjustment and a recovery; the Divisional Head approves it; a duplicate-payment alarm is dismissed as two genuine invoices; the threshold is tuned with its cost on screen; and Internal Audit reads the trail. Every step performs the real action, and it reads itself aloud unless you turn that off.
Guardrails
Tuning with the cost on screen, and a trail nobody can edit.
Proof
A baseline, a controlled pilot, and targets that say they are targets.
A department will not approve AI because it sounds innovative. These are proposed 90-day pilot objectives, to be fixed only after the baseline is measured — not established figures.
| Solution | Proposed 90-day target | Measured by |
|---|---|---|
| Postal financial intelligence | 30% less manual reconciliation time | Staff hours per reconciliation cycle |
| Postal financial intelligence | Fewer balances past the 30-day policy | Unreconciled items by age, against baseline |
| Postal financial intelligence | Verified recoveries and adjustments | Rupees confirmed by officers, not by the engine |
Roadmap
Ninety days, one pilot, then a decision.
Discovery and access
One accountable owner in finance and one technical counterpart. The ledger, bank feeds, money order register and settlement data reviewed; the reconciliation baseline measured; security constraints written down.
Prototype on their process
This demo rebuilt on Pakistan Post’s own accounts with synthetic or authorised, protected data: the match rules, cases, approvals and the audit trail, plus an agreed evaluation plan.
Controlled pilot
One circle or a set of GPOs, run alongside the existing reconciliation. Officers review every case; hours saved, balances cleared, recoveries and false alarms tracked against the baseline.
Business case and decision
Results validated with finance and audit, full implementation and running costs, risks, and a phased rollout with acceptance criteria — through the applicable procurement rules.
Architecture
How it would be built.
Read-only integration first
The engine reads the general ledger, bank statements, the money order register and COD settlements, and writes back nothing but cases. Existing systems stay the system of record.
Rules and models together
Deterministic matching — amount tolerance, date window, split and combined deposits — does the bulk; a scoring model ranks what is left. Every threshold is configuration with a logged approver, not code.
Human approval in the product
Posting, reversing or writing off an entry and recovering money are locked out of the engine in code, not in a setting. Above the approval limit, two signatures.
Roles and access
Accounts Officer, Divisional Head and Internal Audit, each seeing and doing only what the role allows; Internal Audit read-only across everything.
Audit and evidence
An append-only history on every case — time, person, role, action, note — that produces audit-ready evidence rather than reconstructing it afterwards.
Hosted where the data has to be
Deployable on government or in-country infrastructure, with model monitoring, tamper-evident logs and the reporting a pilot evaluation needs.
Scope
What this is, and what it is not.
- It is a prototype built from the published audit reporting and a strategy paper, not a deployed or commissioned system, and it is not affiliated with Pakistan Post.
- Every case, office record, officer, amount and voucher in it is invented. No real account or person is reproduced.
- It holds no data: state lives in the visitor’s browser and never leaves it.
- The pilot targets are proposed objectives, not results. The scorecard’s baselines are invented for the demo; a real pilot measures them first.