Decide when a delivered LR is ready to invoice

The TMS shows a lorry receipt as delivered. Billing still cannot raise the invoice because the POD is unsigned. Another LR has a partial receipt that the customer permits to be billed by accepted quantity. A third is complete but already appears on an unposted invoice.

Create an eligibility queue that explains which service is ready to invoice and why. Delivery, evidence completeness, contractual entitlement and invoice creation are separate states. The pilot should connect them without letting a status change create a second charge.

Bound the first implementation around a billing rule

Choose one customer, one service family and one billing entity. Include its active contract, agreed POD requirements, invoice grouping and correction policy. Start with read access to the TMS and document store, plus a controlled billing workspace where finance can approve proposals.

Name a transport owner for delivered quantities, an evidence owner for POD exceptions, a contract owner for billability and a finance owner for invoice creation. The integration owner handles failed messages but does not decide commercial eligibility.

Record the inputs at their actual grain: LR and leg identifiers, delivered quantities and units, event versions, required documents, document review states, rate version, charge allocation and existing invoice references. File presence alone is insufficient if the required signature or exception review is missing.

Oracle's invoice matching documentation illustrates configured relationships between invoices and shipments. Billing readiness additionally needs the customer-specific evidence and entitlement rules described here. Oracle Transportation Management 26C — Match Rule

Work an LR through the queue

Consider an illustrative customer whose contract permits a fixed ₹6,000 line-haul charge only after full receipt and accepted POD. Waiting charges, if any, require a separate approval. LR-208 carries twenty cartons.

The earlier partial receipt did not authorise 90% of the ₹6,000 charge because this contract charges for completed service. A different illustrative customer could permit ₹300 per accepted carton: eighteen cartons would then support ₹5,400 and the remaining two ₹600. That requires explicit allocation of previously billed quantity. It is not a percentage rule inferred from the delivery count.

Waiting charges can remain unresolved while line-haul is eligible only if the contract and finance process allow that separation. Keep the line states visible even when invoice grouping requires the whole document to wait.

Design the decision record

For each proposed charge, save the service identity, eligible quantity, rule version, rate version, evidence references, approval identity and existing-billing check. A meaningful hold reason should identify the missing action: “signature verification pending with POD team,” rather than “invalid.”

Use a stable identity for the billable service allocation. For LR-208 line-haul, retrying the same approved proposal must return B-901 or its recorded state. A new event version must not create a new obligation key for the same charge.

An approval can become stale. Suppose a POD reviewer withdraws acceptance at 13:41, after finance approval but before invoice creation. The final handoff must recheck the current evidence and approval versions and hold the proposal. If creation already occurred, route the case through finance's correction process. Deleting the invoice locally does not undo the downstream record.

Authorise reads and actions for the relevant customer and billing entity. OWASP's object-level guidance is directly relevant when an integration receives an LR or document identifier in a request. OWASP — Broken Object Level Authorization

Start with a frozen baseline and shadow decisions

Take a dated population of delivered LRs, including open exceptions and already billed services. Preserve every member in the evaluation denominator, even if its records are difficult. Have operations and finance label the expected decisions independently of the proposed automation.

An illustrative ten-LR sample could contain seven eligible, two missing required POD evidence and one quantity exception. If the queue releases all ten, its fast completion is a failure. If it identifies the seven but overlooks that one already has an invoice draft, it is still unsafe to create bills.

Record time from evidence becoming complete to eligibility approval separately from time awaiting the consignee or carrier. The integration should be assessed on what it can change. Monitor false releases, false holds, repeated proposals, unidentified existing invoices and unexplained amount differences.

The first live phase can generate proposals without creating invoices. Move to a supervised creation step only after owners sign off the labelled cases and recovery drill. Set the site-specific acceptance thresholds before the run, including zero unauthorised or duplicate creations in the agreed test set; sample success is not a universal guarantee.

Recover from partial handoffs

When response status is uncertain, neither “failed” nor “created” should be guessed. Preserve the outbound request identity, payload and destination response. A retry must not blindly repeat a non-idempotent creation.

Stop automatic handoffs if duplicate creation, cross-customer access or approval bypass is observed. Continue the existing manual billing process using the same service-allocation register. On recovery, reconcile destination invoices before replaying pending work. Rollback means changing how future work is handled; issued financial records still need authorised correction.

The pilot succeeds when every hold has an explanation

The desired outcome is a billing queue finance can trust. It should release supported services, retain unresolved obligations and show where the next action belongs.

Next actions

1. Select one customer and document its exact evidence and billing rules.
2. Label a baseline containing partial receipts, missing POD and existing invoices.
3. Run shadow eligibility and review every disagreement with the relevant owner.
4. Test stale approvals, timeouts and duplicate delivery before supervised creation.
5. Reconcile every pilot service to an invoice reference or an owned hold.

To scope this pilot, share the TMS and billing system names, the usual reason delivered LRs remain unbilled and the service family to start with. Review can begin with field definitions and redacted examples.