The LR-to-billing lifecycle
OFD and POD sit in the middle of the booking lifecycle. Here is the full sequence:
- LR booking: Consignment created with freight type (PAID/TO_PAY/TBB)
- Dispatch: Added to outward; leaves origin branch
- Unload: Arrives at destination; unloaded from vehicle
- OFD: Added to delivery run; out for final attempt
- Delivered or Exception: Goods handed over, or partial/refused
- POD captured: POD photo and receiver name attached to LR
- Billing: TBB bookings with verified POD ready for GST invoice
What OFD means — and what it does not
"Out for delivery" is an operational milestone: the shipment has left the branch/hub for the final delivery attempt. OFD is not the same as:
- Delivered — OFD means it is on the vehicle, not that consignee accepted
- Auto-billable — you need POD before invoicing TBB
- Proof of acceptance — that comes from POD
A useful workflow keeps these states distinct:
| Status | Meaning |
|---|---|
| Booked | LR created at origin; not yet on an outward |
| In Transit | On an outward between branches |
| Unloaded | Received at destination; ready to add to OFD |
| Out for Delivery | On a delivery run — not delivered, not POD |
| Delivered | Delivery record marked delivered; attach POD image when you have it |
| UnDelivered | Attempt failed — undelivered reason + notes; not billable as a clean delivery |
| Cancelled / RTO | Cancelled LRs are not invoice-eligible; RTO is a separate ops status |
What a useful digital POD should capture
- POD image or scan — stored on the delivery record and named against the LR (not a WhatsApp album)
- Receiver name — who accepted, when the team records it
- Event date/time — required when the delivery is marked delivered or undelivered
- Remarks / undelivered reason — shortages, refusal, reschedule — use notes plus the undelivered reason master
- Link to the LR — findable against the booking, OFD and delivery record
Signature-on-glass and GPS stamp are not claimed here as core TMS fields. Confirm handheld capture (photo POD, OTP, offline save) on a demo of the Android app. Uploading a file is not the same as a branch clerk checking the image is the right LR and legible.
Exception branch: OFD did not become a clean delivery
A useful map is: LR booked → outward (in transit) → unloaded → OFD → delivered or undelivered → POD image on the delivery record → accounts filters TBB for billing. If the consignee refuses or you cannot complete delivery, mark UnDelivered with a reason — do not leave the LR sitting on OFD while WhatsApp argues.
There is no separate product status named "POD verified". Treat verification as a branch/accounts check of the image against the LR before you include that TBB line on a GST invoice.
From POD on the LR to GST billing
For TBB (To BB) customers, a delivery marked delivered plus a retrievable POD image is the operational trigger to invoice — not OFD, and not an automatic GST document. The workflow:
- Delivery team marks delivered/undelivered and attaches POD image
- Branch checks the file is the right LR, legible, and matches receiver/remarks
- Accounts filters To BB bookings (typically delivered) by customer and date range
- Invoice generated from those LRs — no re-keying numbers or charges
"POD received" control: Uploaded ≠ reviewed. The TMS stores the image on the delivery record; your office decides whether that line is ready to bill. Confirm status filters in a demo — cancelled LRs never go on an invoice.
Learn more in GST billing for transporters guide and GST transport billing product page.
Buyer checklist for OFD and digital POD software
When evaluating OFD/POD software, ask:
- Can delivery teams capture POD on mobile — photo, signature, or both?
- Does it work in poor network / offline conditions?
- Is POD attached to the LR, or stored separately?
- Can I see a history of status changes — who marked OFD, who marked delivered?
- Can accounts search for TBB bookings with verified POD for invoicing?
- Is there branch/role permission control for delivery status?
- Can I export POD files and delivery reports?
Frequently asked questions
What is OFD in transport software?
OFD means 'Out for Delivery' — the shipment has left the branch or hub for the final delivery attempt. OFD is not the same as delivered and is not proof of consignee acceptance. A useful workflow keeps OFD, delivered, exception, and POD-received states distinct.
Why does digital POD matter before TBB invoicing?
For a TBB or account customer, verified POD gives evidence that delivery is complete and helps resolve shortages, refusals, or disputes before billing. The software should link POD to the original LR and customer record.
What should a digital POD contain?
Depending on the workflow: a photo or scan of the signed delivery receipt, receiver details, delivery date/time, signature, quantity/condition remarks, and exception notes. The important control is finding the POD against the correct LR with a review trail.
Can digital POD replace paper delivery slips?
Digital POD linked to the LR provides retrievable evidence — POD photo (such as the signed LR copy), date/time, receiver, remarks. For dispute handling, this is more reliable than paper slips that may be lost or illegible.
Connected to LR and billing
POD works best when bookings already live in LR software. After delivery, GST transport billing can invoice TBB without re-keying.
For the "why", read digital POD for transporters guide. Learn about freight types in PAID, TO_PAY & TBB guide.
See also Android phone app (scan, Quick Book, delivery POD), carton scan & labels, iLogitix for transporters or start a free trial.