What makes a freight invoice pack ready to submit?
A pack is ready to submit when the documented checks for that transport job have passed and the team can show what it verified. This is an internal control state, not confirmation that the invoice is correct in every jurisdiction, accepted by the customer or guaranteed to be paid on time.
This article describes an operational control, not the tax or legal treatment of a transaction. Confirm the invoice treatment, payment terms and contractual evidence with the responsible people in your company. For Romanian system obligations, use the guide to RO e-Factura for transport.
A pack that works for one customer may fail another customer’s process. The difference may sit in the transport order, contract, job type, requested evidence or channel through which the customer receives invoices.
Which requirement sources should you check?
There is no universal pack and no hierarchy that automatically resolves contradictions. Inventory the sources that apply, retain the version you used and stop the submission when two requirements do not align.
| Requirement source | What to identify | What to retain |
|---|---|---|
| Customer billing instructions | address, portal, format, references and requested documents | the applicable message, file or page and the date checked |
| Transport order, contract and amendments | service, sell rate, currency, terms and approvals | the accepted version and later changes |
| Job-specific conditions | transport type, stops, delivery, accessorials and required evidence | records and approvals tied to the job |
| Agreed submission channel | email, portal, EDI or another stated workflow | recipient, format and submission identifier |
| Current internal master data | party identity, references and pack owner | the internal source and time of the latest check |
A first-party example shows why instructions must be read precisely. In the DSV Hungary Weblink and invoicing guide, checked on 17 August 2026, the main path sends transport status and POD through Weblink, then sends the invoice separately by email in the requested format. Where delivery status is not required, Weblink was not received or delivery status cannot be entered there, the guide calls for one emailed PDF containing the invoice followed by the POD. These are instructions for that DSV Hungary workflow, not a DSV-wide, legal or industry rule.
When customer instructions and the order conflict, put the pack on hold and ask the named commercial or contract owner to decide. Do not select the more convenient source merely to invoice sooner.
Reconcile the invoice with the transport job
A useful control asks more than whether a file exists. It checks whether the data in that file match the service being billed.
| Control | Match to verify | Owner and evidence |
|---|---|---|
| Supplier and customer | names, addresses and identifiers against the applicable records | partner-data owner and source used |
| References | transport-order number, customer reference and other required codes | where each reference appears across invoice and supporting records |
| Service | description, period, lane or stops where requested | transport order and service evidence |
| Amount | agreed sell rate and approved changes | current commercial approval |
| Currency | currency across order, invoice and customer instructions | applied rule and approval for any change |
| Accessorials | waiting time, extra stops or other approved services | approval and job-specific supporting record |
| Evidence | only the CMR, POD or other files required for that job | file legibility and connection to the correct reference |
| Submission | recipient, channel, format and filename | customer instruction and submission identifier |
These are operational reconciliation controls, not a statutory list of invoice particulars. Freight forwarders should also validate the job result separately; the guide to freight forwarder margin per shipment explains how the customer sell rate, carrier buy rate and direct accessorials fit together.
CMR, proof of delivery and invoice acceptance serve different functions
They are distinct evidentiary functions, even when one document sometimes serves more than one.
Under Article 1 of the CMR Convention, the Convention applies to paid carriage of goods by road when the place of taking over and the designated delivery place are in different countries and at least one is a contracting country, subject to the listed exclusions. Article 4 says the consignment note confirms the contract of carriage, while its absence, irregularity or loss does not invalidate that contract.
For a paper consignment note, Article 5 provides for three originals signed by the sender and carrier: one for the sender, one accompanying the goods and one retained by the carrier. It does not prohibit additional operational copies. Under Article 9, the note provides prima facie evidence of the contract, its conditions and the carrier taking over the goods. Article 9 by itself does not prove delivery to the consignee, invoice acceptance or payment.
Where the 2008 e-CMR Additional Protocol applies, an electronic consignment note that complies with the Protocol may have the same evidentiary value and effects. Among other requirements, the Protocol calls for reliable authentication, accessibility, integrity, detectable amendments and agreed procedures. Romania acceded on 14 March 2019, according to the official treaty status checked on 17 August 2026.
A scan, photograph, uploaded PDF or POD image is not automatically a compliant e-CMR merely because it is electronic. A delivery-annotated CMR may, however, satisfy a customer-defined POD function when the annotation and instructions for that job are sufficient.
Use a ready / hold / escalate gate
Use this gate only for pack readiness. It is not a tax or contract verdict.
| State | When to use it | What releases it |
|---|---|---|
| Ready | documented checks for the job have passed | submission by the internally authorised person |
| Hold | a required match, record or approval is missing | the identified record or approval is obtained and checked |
| Escalate | sources conflict or a commercial, accounting or legal decision is needed | the named owner records the decision and reason |
Define who may release each state. Where the same person prepares and approves the pack, retain at least the completed checks and reasons for exceptions.
Track readiness, transmission, customer processing and settlement separately
Do not compress the workflow into one status. A pack can be sent but not acknowledged, accepted for processing but not yet due, or subject to a question after technical receipt.
| Dimension | Example states | Minimum evidence |
|---|---|---|
| Readiness | ready, hold, escalate | checklist, approvals and decision reason |
| Transmission | not sent, sent, technically received | outbound event and, only where available, channel delivery/receipt evidence |
| Customer processing | not acknowledged, acknowledged, accepted for processing, query raised | explicit portal, email or recipient confirmation tied to the invoice reference |
| Settlement | not due, due, part-paid, paid, disputed | confirmed contract/accounting input and matched payment evidence |
These labels are internal, may coexist and create no legal effect. Sent is not received; technical receipt is not customer acknowledgement; and accepted for processing is not paid. Due status must come from confirmed contract and accounting input. This checklist does not calculate a legal due date.
Resolve exceptions without losing the audit trail
- Assign an owner. An exception without ownership sits between operations, commercial and finance.
- Describe the mismatch. Record the value, reference, file or instruction that does not align.
- Preserve the sent version. Do not overwrite the original file or submission event.
- Obtain the missing record or approval. For an accessorial, retain both commercial approval and the requested evidence.
- Decide what must change. Sometimes only supporting evidence changes; in other cases invoice data may require the applicable fiscal correction process.
- Resubmit through the required channel. Link the replacement to the earlier version and retain the new submission identifier.
- Update only evidenced states. Resubmission does not automatically close the customer query or demonstrate acceptance.
Use the same workflow for a required but missing POD, incorrect reference, currency mismatch, unapproved accessorial, wrong recipient, duplicate submission or customer query.
Common mistakes that can hold up customer processing
- Sending before identifying the instructions that apply to the customer and job.
- Treating the CMR, delivery evidence and commercial acceptance as one confirmation.
- Changing the amount or currency without an identifiable approval.
- Reusing an old address, portal or file format without checking it again.
- Keeping no submission evidence and assuming the pack arrived.
- Overwriting the original version and losing the reason for resubmission.
- Marking the invoice accepted merely because it was sent or technically received.
Test the checklist on one real workflow: choose a customer, record the requirement sources, define evidence for each state and count the exceptions that need clarification before submission. When the process depends on memory or scattered files, the TMS versus Excel comparison shows how to compare the actual configurations without assuming that one tool automatically fixes the workflow.
