Lorry receipts and delivery proofs, checked and matched before billing.

1. Input. Photos and PDFs arriving by email or WhatsApp: lorry receipt (bilty or GR, the consignment note), proof of delivery, invoice copy.
2. AI reads them. LR number, consignor and consignee, invoice number and value, vehicle number, delivery date, and whether the POD carries the receiver's stamp or signature and any written remark.
3. Checks. The LR number exists in your shipment register. The vehicle number matches the one on the trip. The invoice value matches the booking.
4. Exception. A POD with a remark such as "2 cartons damaged" or "short by 5", a blank stamp area or a vehicle mismatch goes to operations. The shipment is not marked delivered.
5. Record. Document links are attached to the shipment in your register, which can sit in your transport management software if it offers an API or data export. Billing sees “POD confirmed by operations” before raising the freight invoice.

The e-way bill number is read from the copy along with the other fields. It can also be checked against the e-way bill portal, using your own login for that system, so what comes back is what the portal shows your business: the number found, the vehicle and the validity date on it. A number the portal does not return, or one whose validity date has passed, goes to operations with the shipment rather than through to billing. The check reports what it sees and decides nothing.

The automation can suggest that a shipment looks delivered. Only an operations user changes the status, because a damage or shortage remark changes what you bill and what the consignee claims. A delivery update to the consignee goes out only if you choose that, and only after operations confirms.

For consignee calls about where a shipment is, see our voice agents page.

Documents rarely come from one place. Each sender’s number or email is linked to a branch, so a photo from an unknown number is held for operations to identify instead of being matched on a guess.