Acumatica and EDI: Why the API Is Only the First Step

Acumatica doesn't have native EDI. If your customers or vendors need you to exchange EDI documents, you will need a third-party solution to make that happen.

There are a few different ways to approach it, and Acumatica's APIs make the connection possible. But connecting to the API is only the first step.

Choosing an Approach

Most companies fall into one of three options:

• Do it yourself - You purchase EDI software and manage everything in house, including the mapping, the Acumatica integration, partner onboarding and monitoring. This works if you have EDI and Acumatica expertise on your team, but that knowledge often sits with one or two people.
• Partially managed - A provider sets up the EDI platform and the mappings, but your team is still responsible for parts of the integration, support or monitoring. It's important to be clear on who is responsible for what when something goes wrong.
• Fully managed - A provider takes care of the EDI platform, the mapping, the Acumatica integration, onboarding and ongoing support. Your team continues to work in Acumatica as usual.

The right choice depends on your volumes, the number of trading partners you have and the resources you have available.

The Acumatica APIs

Whichever approach you choose, the connection to Acumatica will typically use its contract-based REST API. The API allows an external system to create sales orders, read shipments and invoices, and update records. Push notifications can be used to let the EDI system know when something has changed.

The API gives you a way to get data in and out of Acumatica. What it doesn't do is decide what data should be sent, to whom, and when.

The EDI Layer

That's the role of the EDI solution - the layer that sits between your trading partners and Acumatica. It needs to handle:

• Partner rules - Each trading partner has their own requirements. Some want an 855 for every order, others don't. Some connect through a VAN, others through AS2.
• Timing - An ASN should go out once the shipment is confirmed, and an invoice once it's released. Sending too early, or sending twice, causes problems for your customer.
• Workflow - Inbound orders need to fit how you use Acumatica. Should the order go on hold for review? Which order type should it use? What happens if the customer is on credit hold?
• Validation - Before an order is created, the data needs to be checked. Do the item numbers or UPCs cross-reference to your inventory? Is the unit of measure valid? Does the ship-to exist? Does the price match?
• Monitoring - API calls fail and partners send bad data. The middleware needs to catch errors, retry where it makes sense and alert someone when it can't resolve the issue.

Who Owns It?

The biggest difference between the three approaches is who builds and supports this layer. With a DIY setup, it's your team. With a partially managed service, it's often shared, which is where issues tend to fall through the cracks. With a fully managed service, your provider owns it.

If you're working through your first EDI request in Acumatica, or looking at options for an existing integration, we're happy to talk it through. Reach out to us at info@contax.com and ask for Jodi.