Infor EDI Integration: M3 and CloudSuite Order Flow

A new retail account sends you their vendor routing guide. It says you accept EDI 850 purchase orders, confirm with an 855, ship against an 856, and invoice with an 810. You run Infor M3. The question every operations lead asks next is the same: where does the 850 actually go, and what turns it into a customer order?

Infor is a strong ERP for manufacturing and distribution. M3 handles process and discrete manufacturing well, and CloudSuite packages M3 and related applications as a hosted suite. What neither does out of the box is read a raw X12 file and build a customer order from it. That translation and mapping work sits in a separate layer. This guide walks through how Infor structures customer orders, where EDI enters, and the honest trade-offs in each integration path.

What Infor M3 and CloudSuite Actually Are

Infor M3 is the order and manufacturing core; CloudSuite is the hosted suite built around it. M3 runs sales orders, purchasing, inventory, and production. Infor CloudSuite (industry editions like CloudSuite Distribution and CloudSuite Food & Beverage) wraps M3 with cloud hosting, the Infor OS platform, and adjacent applications under one contract.

For anyone coming from a different ERP, the vocabulary shifts. In M3, a customer order is managed through the customer order entry program, and the behavior of each order is governed by an order type you configure ahead of time. Get the order type right and the rest of the flow follows. Get it wrong and orders stall in the wrong status or skip steps they should not.

Infor's own product documentation at docs.infor.com is the reference of record for these programs and their field-level behavior. If you are configuring EDI order handling, keep it open.

How the Customer Order Works in M3

Customer orders in M3 live in OIS100, and their behavior is controlled by an order type defined in OIS010. OIS100 ("Customer Order. Open") is the program where customer orders are entered, viewed, and maintained. Each order carries an order type, and that order type is configured in OIS010 as the master control object for how the order behaves.

The order type decides almost everything downstream. It sets the status profile the order moves through, whether it allocates stock automatically, how it prices, which document outputs fire, and how confirmation and invoicing are triggered. When you set up EDI order handling, you typically define a dedicated order type so EDI-originated orders route differently from phone or portal orders.

For sales-side demand that arrives as a schedule rather than a discrete PO, M3 has a separate path. EDI delivery schedules land in RSS100 ("Delivery Schedule. Open"), which turns incoming demand into customer order lines. This matters for suppliers on planning or release programs, where a customer sends forecast and firm demand over time instead of one PO per shipment. If your partners send an EDI 830, see our 830 planning schedule guide for how that demand is structured before it reaches RSS100.

Where the EDI 850 Lands

Batch and EDI orders enter M3 through the OIS275 interface, then create customer orders in OIS100. OIS275 is the batch order interface program. Your translation layer writes the parsed 850 into the OIS275 staging structure, and M3 validates and promotes those records into live customer orders under the order type you assigned.

The sequence looks like this:

1. The retailer transmits an EDI 850 over AS2, SFTP, or a VAN.
2. A translator parses the X12 segments and maps buyer item numbers to your M3 item numbers.
3. The mapped order is written into the OIS275 batch interface.
4. M3 validates the batch records and creates the customer order in OIS100.
5. The order follows the status profile set by its order type.

The mapping step is where most of the real work lives. The retailer's PO1 segments carry their part numbers, UPCs, or GTINs. M3 needs your internal item numbers, the right customer number, ship-to address, warehouse, and pricing. That cross-reference is the part of onboarding that takes the longest, and it is worth building carefully. For the anatomy of the inbound document itself, our EDI 850 purchase order guide breaks down each segment.

If you want to see exactly what a partner's 850 contains before you map it, paste the file into the free EDI Inspector and read the parsed segments directly. No signup.

The 810 and 856 Flow Back Out

Once the order ships and invoices in M3, your integration generates the outbound 856 and 810. The return path mirrors the inbound one, in reverse.

When you confirm shipment in M3, a delivery record is created. Your integration reads that record and builds an EDI 856 advance ship notice with the carton and pack structure the retailer requires, including SSCC-18 labels where mandated. Timing is strict. Many retailers require the ASN within 24 hours of shipment, and some require it before the truck leaves the dock. A late or missing ASN is a common chargeback trigger. See our EDI 856 ship notice guide for the segment detail.

After invoicing, the integration maps the M3 invoice to an EDI 810 and transmits it to the retailer's accounts payable. The 810 has to reconcile against the original 850, including allowances, freight, and any quantity changes made at fulfillment. Mismatches here are the leading cause of payment disputes. Our EDI 810 invoice guide covers what to check.

Many retailers also expect an 855 acknowledgment confirming you accepted the order or flagging changes, and a 997 functional acknowledgment on every inbound document.

Integration Methods for Infor EDI

Infor exposes integration through Infor ION, the Infor OS platform, and the API gateway. These are the supported doorways into M3 and CloudSuite for any external system, including an EDI translator.

Infor ION is the platform's messaging backbone. It moves documents between applications using Infor's standard business object documents (BODs) and can orchestrate the handoff between an EDI translator and M3. Infor OS is the surrounding platform layer that ION runs inside on CloudSuite. For direct programmatic access, Infor's API gateway exposes M3 APIs that middleware can call to read and write orders, items, and shipments.

You have three realistic paths, each with a different cost and maintenance profile.

Approach	Setup Time	Who Maintains Mapping	Non-EDI Orders	Best Fit
EDI provider with Infor connector (SPS Commerce, TrueCommerce)	8-16 weeks	Vendor (ticket queue)	No	Suppliers with many retail partners
iPaaS / custom via ION + API gateway	3-6 months	Your team or SI	No	Shops with Infor technical staff
Managed service (OrderSync)	1-3 weeks	OrderSync	Yes (EDI + PDF + email)	Distributors at realistic scale

The EDI-provider route gives you a pre-built trading partner network and compliance monitoring, at higher monthly cost and slower change turnaround. The ION-and-API route gives you full control if you have the internal Infor expertise to build and maintain BOD mappings and API flows, and the patience for a longer project. Both assume every order arrives as clean EDI, which is rarely true.

How OrderSync Brings Orders Into Infor

OrderSync ingests orders in any format and creates M3 customer orders through Infor's supported interfaces. The inbound 850 becomes a customer order in OIS100. Shipment confirmation flows back out as an 856, and invoicing as an 810. When a retailer changes their spec, we update the mapping. To connect orders to M3 or CloudSuite with OrderSync, see the Infor integration page.

The part that matters for most Infor distributors is the orders that never arrive as EDI at all. Independent accounts email PDF purchase orders. Some send spreadsheets. Others use buyer portals. A pure EDI translator leaves all of that for your team to key by hand into OIS100. OrderSync reads EDI 850s, PDF POs, and email orders through one pipeline and writes them all into Infor, which is why it fits distributors with a mix of large EDI partners and smaller manual accounts. See how multi-format order processing works and how the ERP integration connects to M3.

If you also run other systems, our related walkthroughs cover EDI NetSuite integration, Oracle EDI integration, Sage EDI integration, and JD Edwards EDI integration.

Before you map a single field, confirm the order type in OIS010. An EDI order routed under the wrong order type inherits the wrong status profile, and every downstream issue traces back to that one setting.

Frequently Asked Questions

Does Infor M3 have native EDI translation?

No. M3 and CloudSuite provide the order interface (OIS275) and integration platform (Infor ION, the API gateway) that EDI documents flow through, but they do not parse raw X12 or EDIFACT files. A translator or managed service handles the mapping between the EDI file and M3's customer order structure.

Where does an inbound EDI 850 go in M3?

The translated order is written into the OIS275 batch order interface, which M3 validates and promotes into a live customer order in OIS100. The customer order's behavior is governed by its order type, configured in OIS010. EDI delivery schedules follow a separate path through RSS100.

What is the difference between OIS100 and RSS100?

OIS100 ("Customer Order. Open") is where discrete customer orders are entered and maintained. RSS100 ("Delivery Schedule. Open") handles EDI delivery schedules, turning ongoing demand from planning and release programs into customer order lines. Suppliers on 830 or 862 schedules use RSS100; one-off POs use the OIS275-to-OIS100 path.

How does OrderSync connect to Infor CloudSuite?

OrderSync connects through Infor's supported integration layers, ION and the API gateway, to write customer orders and read shipment and invoice records. It creates orders from EDI 850s plus PDF and email purchase orders, then generates outbound 856 and 810 documents. Mapping updates are handled for you when a retailer changes their spec.

Can Infor handle both EDI and non-EDI orders in one flow?

Infor itself only ingests structured records through OIS275. To bring PDF and email orders into the same M3 flow, you need a layer that extracts and normalizes them first. OrderSync does that, writing EDI and non-EDI orders into Infor through the same pipeline so your team is not keying the manual accounts by hand.