Sales Order Automation for UK Trade Suppliers

The purchase order comes from your customer. It is their request: these items, this quantity, this price, delivered by this date. The sales order is yours. It is the record in your ERP that you have accepted the request and will supply it. Most UK suppliers copy the customer’s PO number into the sales order so the invoice can quote it later, and that copying step is exactly what an order agent drafts for you.

For a trade supplier the usual run is: the order arrives, someone keys it as a sales order, the order is checked against stock and the account’s credit limit, it is approved and acknowledged to the customer, then picked, packed and dispatched with Royal Mail, DPD, Evri or a pallet carrier, and finally invoiced. An order agent works on the first three steps. People keep the approval, and the warehouse keeps the rest.

In most UK wholesalers and manufacturers it is a sales order processor, a customer service team or an internal sales rep, and in smaller firms the finance person does it between other jobs. With an agent in place that person stops keying and starts reviewing. The agent prepares the draft with the customer, lines and prices filled in, and the same person checks it and approves it in the ERP they already use.

No. A sales order is a promise to supply and it does not post to your accounts. The invoice is the bill, raised once the goods have gone, and for a VAT-registered business it is the document that carries VAT. In most ERPs the invoice is made from the sales order once the goods ship. In Xero, which has quotes and invoices but no sales order record, an accepted quote often plays the sales order role.

Say a garden centre group emails a two-page PDF purchase order for 40 lines, using its own product codes. The agent reads it, finds the account, translates each customer code into your SKU, checks each price against that customer’s price list and each quantity against stock, and writes a draft sales order. Three lines show a price below the agreed list, so the draft is held with those lines highlighted for your team.

They are two sides of one document. Sales order automation, this page, handles the POs your customers send you and turns them into sales orders. Purchase order automation usually means the buying side: raising POs to your suppliers and matching their invoices against them. The same agent pattern does both jobs. Our accounts payable automation page covers the supplier side.

Not as a separate record. Xero’s own published API file has paths for quotes, invoices and purchase orders, with none for a sales order. A Xero quote moves through draft, sent, accepted and invoiced, so many UK firms on Xero treat an accepted quote as the order. Our agent can write the customer’s PO into a draft Xero quote with the reference attached. If you need stock allocation and part shipments, an inventory app or ERP usually sits beside Xero.

Yes. Microsoft’s Business Central API documentation lists a create method for sales orders, a field for the customer’s external document number, a requested delivery date, and a status that can be Draft, In Review or Open. So the agent writes each order as a draft with the customer’s PO number in that field, and your team releases it. We read your environment first, because extensions often add required fields.

Yes. The edition decides the route. Sage’s own UK knowledge base says the Sales Orders module in Sage 50 Accounts is only in the Professional edition, where dispatching an order creates the sales invoice. Sage 200 and Sage Intacct setups depend on the modules and add-ons you license. In the first week we confirm what your edition exposes, and we tell you plainly if the route is weaker than you expected.

Yes, as quotations that your team confirms into sales orders. Check your plan first. Odoo’s developer documentation limits external API access to Custom pricing plans and rules out One App Free and Standard. If you are on Standard, moving to Custom is a cost to weigh before the build. Our Odoo link for Sow Easy, a UK wholesale client, is tested against Odoo’s staging system, with launch still ahead.

Brightpearl’s API documentation says its order message can create sales orders, so the agent can write trade orders straight into Brightpearl beside your web and marketplace orders. Linnworks and Mintsoft usually sit downstream as order hubs or warehouse systems. In those setups the agent writes to whichever system owns the order and price list, and the existing link carries it on to picking and the courier label.

Both can be reached through their APIs, and the record differs. On NetSuite the agent writes the order where your own approval roles already sit, so release happens the way it does today. QuickBooks setups in the UK vary more, and some firms run an inventory app beside QuickBooks that owns the orders. We look at your actual account, edition and add-ons before promising which record the agent will write, and we put that answer in the written quote.

Usually not. Orders from Amazon.co.uk, eBay UK, OnBuy or the B&Q marketplace already arrive as structured data through a connector, so nobody retypes them. The agent is for the orders trade accounts email in. It can share the same SKU checks, so both routes end up in the ERP in the same shape.

There is no single figure worth quoting, because accuracy depends on who sends you orders. The number that matters is a score sheet built from your own past orders: one row per order, one column per field (account, PO number, delivery date, each line’s code, quantity and price), each marked as matching your team’s entry or not. The weak spots in UK trade are usually Excel exports with merged header cells and scanned delivery-address blocks. Any field the agent cannot read with confidence goes to a person.

The draft is held and the line is highlighted with both figures side by side: the customer’s price and the price your system holds for that account. The same goes for a discontinued item, a quantity outside the pack size, an account on stop or a delivery date you cannot meet. Your team decides, and nothing is acknowledged to the customer until a person approves the order.

Yes, and that is most of the work. Trade buyers order using their own codes, old catalogue numbers or a description. The agent builds a cross-reference from orders your team has already matched, then uses it on new ones. When it meets a code it has not seen, it suggests the likeliest SKU and asks. Each answer is saved, so the same code goes through cleanly next time.

Yes, once a person has approved the order. The acknowledgement is built from the approved sales order, not from the customer’s PO, so it shows what you have agreed to supply: items, prices, quantities and the dispatch date. If you are sending fewer than were ordered, splitting the delivery or offering a substitute, the email says so in plain words before it goes.

Only if you decide that it should, for cases you name. At launch every draft waits for approval. Once a few weeks of drafts have been checked, you can choose to let repeat orders from known accounts, inside a value limit, go straight through. That decision is written down, can be reversed, and never covers a new customer, a new item or a price exception.

Indirectly. Making Tax Digital for VAT applies to your VAT records, and the sales invoice is where VAT is recorded, not the order. HMRC’s VAT Notice 700/22 says copy and paste is not a digital link and that moving data by hand between software is not acceptable. An agent that writes orders by API, so the invoice is raised from the order inside your system, keeps that chain digital.

It is relevant to what happens after them. Under the plan set out by GOV.UK, every VAT invoice in the UK must be an e-invoice from 2029, and the technical standard is still to be picked. Suppliers whose invoices are raised from clean, structured sales orders will find that change easier. The agent does not send e-invoices, but it gets your order data into the shape that makes them simpler later.

A buyer’s name and work email are personal data, so the agent is set up as processing for you under your instructions. ICO guidance on controller and processor contracts says a processor may act only on documented instructions and may not add another processor without your prior written authorisation. Before the build you get a written list of every service the order data passes through, including the AI model provider.

For a build, published ranges for UK projects run from £10,000 to £90,000. LeverX gives £10,000 to £30,000 for one workflow, and £30,000 to £80,000 for a multi-step agent, using an order agent that writes to an ERP as its example; it does not state VAT. Fulminous gives £30,000 to £90,000, ex VAT, for a back-office data entry agent. FactoryJet gives a fixed price in writing after a short scoping call.

The written quote gives the date, and it depends on your setup more than on the agent. Three things in UK setups add time. Sage 200 run on a server in your office needs a secure route in before anything can be written. A second Business Central or Sage company means a second set of price lists and rules. EDI from a large UK retailer runs on that retailer’s own format and testing timetable, which we do not control.

Yes. Pick a recent month of trade orders from the accounts that cause the most retyping, include the Sage, Business Central, Xero or Odoo records your team made from them, and send both. The demo comes back as drafts in the shape your system expects, plus the score sheet and the lines that would have been held. You decide from that whether to go further.

You own the agent, the code, the part-number cross-reference and the test orders from day one, and they can run in your own cloud account with the AI and hosting billed to you at cost. Defects are fixed inside the build price for a cover period agreed before work starts. Support is optional: FactoryJet can keep managing it, with each change quoted and approved, and no monthly minimum.