If you sell cash-on-delivery in South Asia or MENA, the money problem is not the sale — it is getting paid. A courier picks up 400 parcels, delivers some, returns others (RTO), collects cash on the rest, and then remits a lump sum days or weeks later with a CSV or PDF that never lines up cleanly with your orders. ERPNext core has no concept of "cash the carrier is holding on our behalf." You end up booking a Payment Entry when the parcel ships (overstating cash) or only when the remittance clears (losing all order-level traceability), and either way a finance person spends days each week eyeballing courier statements in Excel to find the shipments that were delivered but never paid, the ones paid short of the invoice, and the COD fees the carrier quietly netted out. That reconciliation gap is where COD margin leaks.

We build a proper Frappe app that models this end to end. A COD order gets flagged (a custom field plus a COD Shipment DocType that links the Sales Order / Sales Invoice, the carrier, the tracking number, and the expected collectible amount), and each shipment carries an explicit lifecycle state — In Transit, Delivered / Cash Held, Remitted, RTO, Short Paid. A hooks.py doc event on Sales Invoice submit creates or updates the expected-collection ledger so the cash the carrier owes you is visible as a first-class number, not an inference. When a carrier remittance arrives, you import their file through a Carrier Remittance DocType with per-carrier column mappings; a whitelisted server-side method matches each remittance line to the right shipment by tracking number, order reference, or amount-and-date heuristics, books the correct Payment Entry (net of the carrier's COD fee, posted to a configurable expense account), and marks anything it cannot confidently match for human review rather than force-fitting it.

The reconciliation logic is deliberately conservative: it never guesses when a match is ambiguous. Discrepancies — delivered-but-unremitted past your agreed remittance SLA, amount collected less than invoiced, duplicate remittance lines — raise alerts and land on a review queue with the exact variance. RTO and refund cases reverse the expected collectible and, where you want it, trigger the downstream stock and credit-note handling so your books and your COD ledger stay in step. A scheduler event runs the aging and SLA checks on a cadence you choose, and role profiles keep the courier-file importer, the finance approver, and the read-only ops viewer on separate permissions. Reports include a per-carrier COD aging report (how much cash each courier is sitting on and for how long) and a reconciliation exceptions report. Everything is reachable over the standard Frappe REST API and whitelisted methods, so an external courier portal or a webhook from your shipping aggregator can push remittance data straight in.

This is build-to-order, not an instant download. We start with a short scoping call to capture your carriers, their file formats, your COD fee structure, and how your Payment Entries and RTO flow should post. You get a fixed scope and quote, we build against a clone of your bench, and we deliver — typically 2 to 4 weeks from confirmed scope — with UAT on a staging site, a rollback plan, the full git repository, and a post-go-live support window. It runs as a normal installed app on your Frappe/ERPNext v15 or v16 bench; nothing about your upgrade path changes.