EDI Onboarding: How Orderful Slashes Onboarding Time From Months to Less than 5 Days

EDI is one of the few older technologies that still works—but it typically causes headaches for anyone who uses it. There are many challenges with EDI, however, one of the biggest challenges is onboarding new trading partners, a process that takes far too long.

Most companies have come to accept 8-10 week EDI onboarding times. They don’t try to streamline the process because they think it has to be this way—but they’re wrong. Let’s take a closer look at the current EDI onboarding process, identify opportunities for improvement, and explore how we can streamline EDI onboarding from months to days.

EDI onboarding is driven by humans, which includes back and forth feedback loops that aren’t in real time. This results in wasted time and delays. When you engage a new trading partner, there are many steps your team must go through before you can successfully start trading with your new partner. If you are performing EDI onboarding with a new partner, below are the steps you can expect.

1. Requirements Gathering: Every partner has a set of guidelines which define the EDI transactions they expect to transact with you. These guidelines define the content, structure, and the way in which you must send the data to them. Each partner you work with will have unique requirements. For example, one partner might send you an 850 purchase order that contains an SDQ segment identifying which locations to ship the order to. While another partner might send one 850 purchase order for each shipment location. The guideline requirements define how you will integrate with each partner, which is guaranteed to be unique.
2. Inbound EDI Integration and Mapping: Next you need to figure out how you are going to receive inbound transactions and get them into your system of record. Understanding both your system requirements, the data needed by your ERP or system of record, and the content in the inbound transaction, which is outlined in the guidelines, will be key to building your integration. Now you will need to decide what data you need to create the transaction in your own system. For example, if you receive an 850 purchase order, it may include data you don’t need in your system of record like a vendor number. However, it may be important to store the data so that it can be used in your outbound transactions.

   Most EDI developers will convert the transaction into a data format they can understand. This can come in the format of XML, JSON, a CSV file, or even database records. EDI data is sent as a flat file that is asterisk delimited and most systems can’t process this data natively. This job of converting the data from an EDI format into something your system of record or ERP can understand can be complicated. Most modern ERPs have APIs while legacy ERPs have staging tables to process data. Either way, this will require a developer to parse the EDI file and reconstruct it into a format your ERP can understand.

3. Outbound EDI Integration and Mapping: Similar to inbound transactions, you need to take data from your system of record and generate the EDI transaction in the format that matches the guidelines. The most common way of doing this is to use EDI field mapping software. However, the challenge with creating outbound transactions is you need to follow the specific guidelines of the trading partner. Most EDI tools do not validate your data against those guidelines. If validation is available, it simply compares the generated EDI file to generic EDI specification, which does not take into consideration the uniqueness of your trading partners guidelines.

   Because most EDI software providers don’t provide validation against your trading partners actual guidelines, and it is difficult to uncover errors in your transaction with your eyes, you will need to do a lot of testing.

4. EDI Scenario Testing and Validating: Once you have completed the integration for each document you must now test and validate the work. This is the most time intensive part of EDI onboarding. Each individual document must be validated in the order that your partner defines, which means you must send a sample or test transaction to your partner based on the inbound data they sent to you. For example, if you are testing in a retail scenario, your partner will send you an 850 purchase order and you must respond with the proper outbound data. This may include an 810 invoice, an 856 advance shipment notice, and an 855 acknowledgement that all have related data from the inbound 850 purchase order.

   Your partner will validate the transaction either electronically or manually. If the transaction is invalid, you will have to re-engage your developers to make changes, then try again. This process of back and forth can take weeks to ensure each document is valid prior to sending live transactions. For many partners, this process is handled over email. Trading partners like Walmart or Amazon have portals providing self-service scenario testing. However, most retailers, or what we at Orderful call “Leaders” as they define the requirements, do not have a self-service experience. This manual back and forth validation and testing can take months to accomplish.

5. Setting Up the Communication Channels: Each partner will require you send and receive data in a unique way. Some will choose to use a VAN, AS2, or SFTP. Even though you might use the same technology to trade with multiple partners, each connection is unique and requires configuration. Communication infrastructure is typically hosted on its own server because it’s critical to the lifecycle of these transactions and you have to account for scale.
6. Handling EDI Acknowledgements: EDI acknowledgements are known as 997s. Since EDI was founded before the concept of the internet, these are a critical way to confirm the receipt of a transaction. Think of these 997s as a handshake between you and your trading partner’s system. Your trading partner will send you a 997 once they have processed the transaction in their system of record and you will be required to send 997s when you process the transaction in your system. These 997s are typically built into the communication channels of systems, meaning it automatically gets sent, downplaying the importance of validating that the transaction was created in your system. Best practice would be to generate these acknowledgements after you’ve created a valid transaction into your system of record.
7. Live Trading and Troubleshooting: Now that you’ve completed the steps above, you are ready to begin transacting with your partner. Live transactions are sensitive. If they process cleanly and create records in your system, you will see these transactions in your backend. If you send accepted transactions, you will receive valid 997s from your partners. Monitoring this is important and often overlooked. While you’re trading production data, it’s important to have the right notifications in place when something doesn’t work. For example, if a partner sends you a part number that your system doesn’t recognize, you will want to understand what it is they were trying to order. If you don’t, you could be losing out on valuable revenue. The same goes for outbound data like invoices. If your invoices fail to deliver to your partners due to data errors or communication channel errors, you will want to know there is something wrong so you can resend or notify your partner that the invoices are coming and delayed. If these invoices go unnoticed, it’s likely that your partner will never pay for the product and you will have to reconcile these challenges at a later time.

You must follow these steps for each partner and transaction type. This process of EDI onboarding quickly becomes a full time job. It’s the lifeblood of your business and defines the execution between you and your supply chain. The work involved takes unique skills to parse EDI transactions, understand your system of record, manage communication channel infrastructure and create production notification services that quickly become complex. Many enterprises end up with hundreds of point-to-point mappings and custom code to detect these kinds of errors. These complex integration environments become an EDI headache. However, your business depends on EDI and you must get the job done.

We’ve reimagined how you can onboard EDI trading partners. We built modern EDI infrastructure that focuses on simplifying EDI integrations, reducing EDI onboarding times and eliminating the complexity of communication channels and notifications.

1. Requirements Gathering: When Orderful onboards a trading partner, we do it once. This means that we take their guidelines and communication channel requirements and we publish them onto our platform. This process takes us less than a day. Once the new trading partner is set up in the Orderful Network, anyone can reuse those requirements immediately.
2. Inbound EDI Integration: Orderful offers a feature called integration assistance that makes EDI data mapping simple. We consolidate your trading partner’s inbound unique requirements into one format which includes a super-set of all the data you will receive. This enables your developer to integrate your back end systems once to our API, consuming data from all your trading partners in a common format that can then be integrated into your back end systems.

   Orderful can convert the inbound EDI transactions into a modern, parsable JSON structure. This happens automatically in the Orderful platform, allowing your team to view both the original X12 payload and the converted JSON payload within the Orderful UI.

3. Outbound EDI Integration and Validation: Similar to inbound transactions, you will integrate to Orderful using our integration assistance feature for outbound transactions. Your developers can use the Orderful API to integrate one time per transaction and can send data to Orderful using a JSON data structure. The Orderful platform converts JSON data into X12, processes the transactions, and immediately validates them against not only the X12 schema but also validates against your trading partner’s unique requirements at the same time.

   Validation in the Orderful platform happens in real time. On top of making EDI integration simple with our integration assistance tool, we also give your team real-time feedback on your transactions. Instead of waiting for your partners to respond over email with validation errors, Orderful clearly shows you validation errors. You can then choose to fix those problems in your system of record, in your integration, or using the Orderful Business Rules Engine.

4. Business Rules Engine: Orderful’s Business Rules Engine allows business users the ability to make necessary modifications to EDI transactions that previously would have taken a development resource. Business users can perform simple actions like replacing values, moving elements, and writing if statements, using syntax similar to writing formulas in Excel. In addition, Orderful provides more complex rules to solve the unique needs of EDI like turning around data from inbound transactions into outbound transactions. The vendor number example used previously is a good use case for these rules. Vendor numbers, which may come inbound on a 850 Purchase Order, are rarely stored in a system of record. However, they are important to your partner to recognize who you are, so you must turn this data around from the inbound transaction and add it to the outbound transaction.



5. EDI Testing and Validating: Orderful provides built in scenario testing and real-time validation. That means that we allow you to run full end-to-end testing within the Orderful platform to ensure your data meets the digitized requirements. If there is an error, there is no need to bring your development team in, as Orderful has a built in Business Rules Engine that allows non-developers to write rules and fix errors within the UI. You can then take these valid transactions and share them with your partner ensuring that they will be accepted.
6. Communication Channels: Each partner will require you to send and receive data in a unique way. Some will choose to use a VAN, AS2, or FTP. You don’t have to do anything to stand these up on our platform. Our team handles setting up and managing communication channels for you.
7. Live Trading and Troubleshooting: Once you’ve generated valid data within the Orderful platform and your partner has accepted it, you are ready to start sending production transactions. These transactions flow freely and in real-time from Orderful to your partner. If there is an error in any step of the process from data validation, communication channels, or acknowledgements, you can configure notifications in the UI to send you an alert. We’ve built a notification service that allows you to be sure that you’re sending and receiving your critical supply chain transactions successfully.

This new cloud-based approach to EDI onboarding allows you to get to market 80% faster. As your company grows and you continue to add trading partners, our goal is to get you to production as fast as possible. Decreasing EDI onboarding times from months to days means going live sooner, resulting in increased revenue and an improved bottom line.

Our customers no longer spend their resources reviewing complex guidelines, building one off integrations, going through weeks of manual testing, or managing complex infrastructure.

They simply set up an integration once to our platform, test with their partner, and start using our infrastructure that does the EDI heavy lifting.

If your organization is switching ERPs, changing system integrators, upgrading your ERP, or evolving through digital transformation, considering Orderful as your cloud EDI platform would be smart. We’re here to help, and we’d like to show you the Orderful difference. When you’re ready, schedule some time with one of our EDI experts.