How Leopards pays your COD, and how to check it

A delivered parcel's COD is paid on a Leopards invoice. Until it is, Leopards' own payment detail for the parcel reads Invoice not generated yet., which is the courier telling you, per parcel, that it holds your money. The first real account ShipOps connected showed ₨6,197 sitting in that state.

Leopards does not publish a fixed payout day. Invoices in the accounts ShipOps has read arrive at a regular rhythm per account, paid by IBFT (a Faysal Bank transfer on the ones seen) or cheque, and ShipOps learns your rhythm from your invoices to forecast the next one.

An invoice is identified by its cheque number, a code like IBOS227232488, with a cheque date and a printed cheque amount. Leopards' API lists invoices by date range, gives payment details per parcel (status Paid, the invoice it was paid on, the date), and gives shipping charges per parcel (gross charges and GST). No single call lists an invoice's parcels, so the membership has to be rebuilt by joining those planes.

Per parcel, the money is: collected equals COD when delivered and zero when returned; shipping charge equals gross charges minus GST; GST as printed; net equals collected minus gross charges. A returned parcel lands with a negative net, which is the real cost of that RTO.

The printed cheque total is not reconstructible from the per-parcel rows. On every real invoice ShipOps has read the delta flipped sign between invoices (plus ₨7.4k, plus ₨16.3k, minus ₨8.1k on three consecutive ones) because a parcel's COD can ride a different cheque than the invoice its payment row names. Account-wide the books close within about 5%. ShipOps keeps the printed total as the cash-in-bank figure and reconciles on the per-parcel truth, which is what your orders can be checked against.

These are the discrepancies ShipOps finds on Leopards receipts, in the order they usually cost the most:

• Delivered, "Invoice not generated yet" for weeks. The parcel is delivered on the trail, Leopards admits it is unpaid, and no invoice arrives. This is the cleanest claim there is, because the courier's own API states it.
• A paid parcel the charges plane does not know. Leopards' shipping-charges call silently drops parcels it has no row for. A paid parcel with no charges would otherwise look like a full COD remitted with zero deductions; ShipOps marks the receipt partial instead and asks again later.
• COD on one cheque, payment row naming another. The cross-invoice drift above. Not money lost, but the reason a cheque total never matches the sum of "its" parcels.
• Another shipper's parcels in your money. On a master key, a sister business's deliveries and returns land in your receivables unless scoped out. Hide the shipper and they leave your figures.
• Return charges on a parcel you did not expect back. A "Delivered to Vendor" read as a delivery hides a return charge inside what looks like a short payment.

ShipOps sweeps Leopards' invoices on a schedule: list invoices in the window, enumerate parcels booked in the 120 days before the oldest invoice, read payment details in batches of 50, keep the rows marked Paid with a real cheque number and date, add the shipping charges, and file one receipt per invoice. The membership is anchored to the invoice dates, never to the sweep window, so a re-sweep reproduces the same receipt and can never un-pay a parcel.

Every row is matched to a parcel. The Money screen shows what reached the bank, what Leopards still owes (delivered parcels with no paid row, which is exactly what "Invoice not generated yet" means), and what is at risk. Returns are priced from their negative net. The CSV of unpaid parcels is what you send your Leopards account manager.