A Customer Has Set an EDI Deadline. What Do You Need Ready?

A large customer wants electronic orders and invoices by a fixed date. Your team still works through email, spreadsheets and the accounts package. The deadline is now a commercial problem as well as a technical one.

The first job is to find out exactly what the customer will accept and what your operation must do to produce it. Buying a connector before answering those questions can leave the hardest work untouched.

At Everything Boxed, we delivered the order and invoice flow required to keep its biggest customer. At Miranda, the work included budget checks, order matching and invoice approval. These are different processes, even though both involve electronic documents. The checklist below is a starting point for scoping your own project.

1. Get the customer's actual specification

Ask for the onboarding pack, document specifications, example files, connection details and the name of the person who signs off testing. Confirm which messages are required for the first release: purchase orders, invoices, acknowledgements or other documents.

Record the deadline, the customer's test windows and any dependency on a trading network or another supplier. A format name alone is not a specification. Our TRADACOMS invoicing work had to meet the receiving merchant's particular requirements as well as generate the right file structure.

2. Trace each field back to a source

Take a real order and invoice through the process. Where do product codes, quantities, prices, delivery addresses, tax values and purchase-order references come from? Which system owns each value? Who corrects it when the customer's reference does not match yours?

Write down the mappings and missing data. Include units and rounding rules where they matter. A file can be structurally valid and still contain a price or reference the customer will reject.

3. Agree the approvals and exceptions

Decide which documents can move automatically and which need a person to review them. That may include an unknown product, a price difference, an exceeded budget or an invoice that does not match the order.

Give each exception an owner and a visible queue. The operations team needs to know what happened, what is waiting and what to do next. A technical error buried in a log does not help someone answer a customer's call.

At Miranda, daily invoice preparation was automated while the operations team kept approval before sending. Automation did not remove that decision from the business.

4. Test the whole transaction, including failure

Agree acceptance tests with the customer and your operations team. Use representative documents and check the resulting records in both systems. Include:

• An ordinary order and its matching invoice.
• Missing or incorrect references and rejected documents.
• A repeated document, so a retry does not create another order or invoice.
• A dropped connection and the return to normal service.
• Corrections and any credit-note flow included in the scope.

If no test or staging environment is available, build a mock of the customer's interface from their specification and sample documents. Use it to test valid messages, rejections, retries and connection failures without sending live orders or invoices. Record the assumptions in the mock and agree a final check against the real system with the customer before switching over.

Keep a record of the tests and who accepted them. Successful transmission is only one part of success; confirm that the receiving system accepted and processed the document as expected.

5. Plan the switch to live trading

Agree when the old process stops, which open orders remain in it and how the team will reconcile documents during the change. Assign someone to check the first live transactions with the customer.

Write down the fallback if a critical check fails. A manual route is useful only if the customer accepts it and both sides know how to avoid duplicates when automated processing resumes.

6. Decide who owns it afterwards

Name the people responsible for failed documents, connection problems, specification changes and software updates. Agree access, monitoring and support hours. The build contract and ongoing support agreement should make those responsibilities clear.

You do not need every future report before the deadline. You do need a reliable route through the required transaction, with checks and people able to handle the exceptions.

If you have the customer's specification and a date, our EDI integration service is a place to start. Where the surrounding process also needs changing, digital ordering and procurement covers the checks, approvals and operational workflow. Send us the requirement and we will scope the first release.