EDI Order Intake in Business Central: From Customer Schedules to Firm Orders

No documented standard feature in Business Central turns a customer’s EDI message into a sales order. Whatever carries the message, a portal worked by hand, the API or a connector, the decision that shapes the project comes first: which document each message lands on. A rolling schedule belongs on a blanket sales order. A firm call-off belongs on a sales order made from it. Get that model wrong and the best interface in the world will only automate the mess.

The question came up while scoping a manufacturer’s project, where one large customer runs its purchasing through a supplier portal. That customer sends a forecast, then firm orders, then keeps revising dates and quantities as its own plan moves. The supplier has to confirm each change. The connection is the part everyone asks about. The document model is the part that decides whether the ERP still makes sense six months later.

What does EDI order intake actually mean for a supplier?

It means receiving several kinds of message, not one. Supplier portals used in automotive and other industrial supply chains carry purchase orders, delivery instructions (the call-offs), demand forecasts, order confirmations, and shipping and transport data. SupplyOn, one of these platforms, lists all of these among the transactions it handles.

The same platform offers two ways in, and they matter for the budget. Its WebEDI option, in SupplyOn’s own words, “requires a PC, a browser and Internet access”: the supplier reads the customer’s messages as web forms and can download them as CSV files. Classic EDI connects the supplier’s system directly, over OFTP2 or AS2.

So “EDI” can mean a person reading a web page and typing the order into the ERP, or a machine-to-machine flow. Both are real options. The first costs time on every order, the second costs a project once.

Does Business Central take EDI orders out of the box?

Not for incoming customer orders. Microsoft documents its e-document features in two directions. On the sales side they send documents, sales invoices, sales orders and credit memos among them. On the purchase side they receive vendor invoices and credit memos, which can be linked to existing purchase orders. None of the documented scenarios receives a customer’s order and turns it into a sales order.

Microsoft’s own order-taking automation, the Sales Order Agent, works on a different input: it monitors a Microsoft 365 mailbox, reads customer emails, and always creates a sales quote as its first step. It uses Copilot Credits, billed to the company. That fits customers who order by email. It is not built for a portal that sends structured schedules.

What remains is the API. Business Central API v2.0 exposes salesOrders and salesOrderLines, both of which accept a POST to create records, so a middleware or connector can write orders directly. We cover authentication and the traps of that route in our Business Central API guide for developers. The API tells you how to write a sales order. It does not tell you whether a sales order is the right thing to write.

Which Business Central document should a customer schedule land on?

The forecast part of a schedule belongs on a blanket sales order. Microsoft describes it as a framework for a long-term agreement, typically for a large quantity delivered in small shipments over time, with each shipment set up as its own line. The key property is stated plainly: quantities on a blanket order don’t affect item availability. It is a worksheet for monitoring, forecasting and planning, not a commitment to ship.

Planning still sees it. In Business Central’s planning logic, a blanket order is a customer-specific forecast on top of the general demand forecast. Sales orders linked to a blanket order line consume that anticipated demand, and consumption doesn’t reduce the blanket quantity itself.

The firm part of the schedule becomes a sales order, made from the blanket order with the Make Order action. Four behaviours from the documentation shape the design:

• Before Make Order, you clear Qty. to Ship on every line you don’t want to ship yet. The new sales order still contains those lines, with a blank quantity, and someone has to decide whether to delete them.
• A sales order line can’t exceed the quantity of its blanket order line; if it does, the order can’t be posted.
• Once a sales order covers the full quantity of a blanket line, no further order can be made from that line. To add quantity, you increase Quantity on the blanket line.
• Posting the sales order updates Quantity Shipped and Quantity Invoiced on the blanket order, which stays in place until you delete it.

A workable rule follows from that: everything inside the customer’s firm horizon is a sales order, everything beyond it is a blanket order line. The interface’s job is to move quantity from one to the other as the horizon rolls forward.

What happens when the customer revises dates and quantities?

This is where intake design gets hard. A portal schedule is not a document you receive once. It is a stream of revisions, and each one can move a date, change a quantity or cancel a line.

Three decisions have to be written down before anyone builds the flow:

• Where a revision lands. A change beyond the firm horizon updates the blanket line. A change inside it touches a sales order that may already be released, picked or in production. Those two cases need different rules, and the second one needs a human.
• How messages are matched. Keep the customer’s own order number in External Document No., which Business Central carries into posted documents and lets you search by. Map the customer’s part numbers with Item References, so the sales line shows their reference and your item number side by side.
• What gets confirmed back. The customer expects confirmations of dates and quantities over time. A confirmed date is a promise, and it should pass the same checks as any other promise. We describe how to gate it in a two-step approval workflow for delivery dates.

When nobody decides these three points, the interface decides them by default, usually by overwriting whatever is in the ERP with the latest message.

When is a quote-to-order flow the better model?

When the customer sends a request rather than a schedule. For parts that are quoted from drawings, the path is opportunity, then quote, then order: Business Central creates a sales quote from an opportunity (for a contact of type Company) and turns an accepted quote into an order with Make Order. Sales quotes don’t affect planning or availability, which is why the Sales Order Agent uses them as its safe first step.

A supplier can run both models at once, one for series parts ordered on a schedule and one for new parts ordered on request. The mistake is forcing both into one document type because one customer uses a portal.

Should you build an interface for one portal customer?

Only after the standard has been tested against the real flow. A sensible order for scoping: check first that the process fits standard Business Central, then identify what needs specific development, then list the interfaces, and sort those into critical and non-critical. A portal integration sits in that list alongside every other integration competing for the same budget, and it has to earn its place like the others.

The first question is how many customers actually send orders that way, and how often a schedule changes. If one customer sends a handful of revisions a week, a browser session and a disciplined blanket order process may be enough for the first year. If several customers send daily schedules, re-typing becomes a daily source of errors, and a connector writing through the API is a small, well-bounded piece of Business Central development.

Either way, the document model from the previous sections comes first. An interface built before it simply fixes the wrong answer in code.

The Asio Services way

Start an intake project on paper, not in the portal settings. Write one page: which messages the customer sends, which Business Central document each one becomes, where the firm horizon sits, what a revision is allowed to change without a human, and who confirms dates back. If that page can’t be written, no connector will fix it.

If your customers already send schedules you re-type by hand, or you are about to commit to an EDI project, the Clarity Form is where we look at the flow before anyone chooses a tool.

FAQ

Can Business Central import EDI sales orders without an extension?

Not through a documented standard feature. Business Central’s e-document features send sales documents and receive vendor invoices, and the Sales Order Agent reads emails. Structured customer orders arrive through the API v2.0 salesOrders endpoint, a connector or an extension.

What is a blanket sales order used for in Business Central?

It records a long-term agreement delivered in several shipments, one line per shipment. Its quantities don’t affect item availability, but planning treats it as a customer-specific forecast. Firm orders are created from it with the Make Order action.

How do I keep the customer’s order number and part numbers?

Store the customer’s order number in the External Document No. field on the sales header, which is carried to posted documents and searchable. Use Item References to map the customer’s part numbers to your items.

Is WebEDI enough instead of a full EDI integration?

It can be, when few customers use a portal and schedules change rarely. WebEDI needs only a browser, and messages can be downloaded as CSV, but every order is still handled by a person. As volume and revision frequency grow, the case for an API-based connector gets stronger.