SM Space · EDI & Document Exchange
EDI Software for Customer Purchase Orders
SM Space EDI is the EDI software inside the SM Space ERP system. When a customer sends an X12 850 purchase order — the standard electronic form of a purchase order — it works out who sent it, maps their part numbers to yours, and creates a sales order. It sends back a 997 acknowledgement and keeps the original file.
Inbound customer purchase orders, done properly. Your customer’s order becomes a draft sales order in the same numbering series as one somebody types in.
Last updated: September 2026
A file becomes an order
PO-88213 · X12 850 · Northgate Ltd
ST*850*0001
BEG*00*SA*PO-88213**20260910
PO1*1*40*EA*41.20**BP*SKU-99120- partnerNorthgate Ltdfrom the envelope
- partSKU-99120 → BRK-4471cross-referenced
- resultSO-000914 · draft997 sent back
a draft, in front of the credit check — exactly where a typed order lands
The same order, twice
two files, one order
- 09:02File ASO-000914 created
- 11:40File B — same order, new envelope✗ not created again
reprocess File A ✗ already linked to SO-000914
the envelope changes every time; the order does not, so the order is what is fingerprinted
A change, refused
PO-88213 · twice
- purpose 00new order✓ SO-000914
- purpose 04change✗ refused, parked for review
a change treated as a new order is two shipments
recognised and declined — not unsupported, and never guessed at
Where it broke
EDI-000442 · failed
- segmentPO1line 14
- element07value “SKU-99999”
- reasonno cross-referenceoriginal file kept
- fix & reprocessSO-000915one order, not two
not “invalid document”, and not a 4,000-line file to count through
Above: an X12 850 purchase order arriving, being matched to a trading partner by the sender ID in its envelope, having the customer’s part number cross-referenced to ours, and becoming a draft sales order with a 997 sent back; the same order arriving a second time in a new envelope and not being created twice; a change order refused rather than treated as a new order; and a failed file naming the exact segment, line and element that broke, then being fixed and reprocessed into a single order.
What you can do
- Take X12 850 purchase orders from your customers, out of a folder SM Space watches
- Have them become real sales orders, numbered by your own sales numbering rule
- Work out which trading partner sent a file, from the file’s own envelope
- Map your customer’s part numbers to yours
- Send back a 997 acknowledgement, saying what actually happened rather than a blanket yes
- See how a file will land before it lands, without creating anything
- Catch the same order arriving twice, three different ways
- Fix a failed file and reprocess it without creating a second order
- Keep the original file exactly as it arrived, and download it
01
EDI Orders Follow Your Normal Rules
An order that arrives by EDI is not a special kind of order.
It becomes a draft sales order — the same draft a salesperson would have typed, numbered from your own sales numbering rule, so SO-000914 is just the next one in the series.
What SM Space EDI deliberately does not do is confirm it. Your credit check, your stock reservation and your backorder rules all live on the Confirm step in Sales, and an EDI order arrives in front of that step like every other order. So a customer over their credit limit does not get through by sending the order electronically. The electronic route does not skip the step — it lands ahead of it.
The module owns no order table of its own, so there is no second copy of your sales process to drift out of step with the first. The price on each line is the price your customer put on their own purchase order, which is exactly what you want to see on a draft before you accept it.
ISA*00* *00* *ZZ*NORTHGATE *ZZ*SMSPACE *260910*0902*U*00401*000000117*0*P*>
GS*PO*NORTHGATE*SMSPACE*20260910*0902*41*X*004010
ST*850*0001
BEG*00*SA*PO-88213**20260910
PO1*1*40*EA*41.20**BP*SKU-99120
- Trading partnerNorthgate Ltd from sender ID ZZ/NORTHGATE
- Their part number SKU-99120 → BRK-4471 cross-reference
- Purpose code00 · new orderBEG01
- Their referencePO-88213 kept on the order
- Sales orderSO-000914 your own numbering series
- Status Draft credit check runs at Confirm, as always
- 997 sent backaccepted one per functional group
02
Duplicate Order Prevention
Three different things get called “a duplicate”, and they need three different answers.
The same file arrives twice. Trading partners resend an identical order in a fresh envelope, so SM Space ignores the envelope and fingerprints the order itself. The database enforces it rather than a lookup, because two processes can read the same folder at the same moment and both decide the file is new. When a resend really is a second order, an operator can say so.
The same order arrives inside two different files. A softer signal, so it is parked for somebody to look at rather than posted or thrown away.
Somebody reprocesses one that already posted. The link between the message and the sales order is written in the same commit as the order, and the database refuses to let two messages claim one order. Press reprocess on PO-88213 after SO-000914 exists and you get a sentence naming it, not a second order.
-
01
The same file, twice no second order
File B carries PO-88213 in a fresh envelope
The order itself is fingerprinted, not the envelope. A unique index refuses it, so two processes reading the folder cannot both slip one through.
-
02
The same order, two files parked for review
PO-88213 seen again under a different document
A softer signal, so somebody looks at it. Nothing is posted and nothing is thrown away.
-
03
Reprocessed after posting refused by name
Somebody presses reprocess on EDI-000441
“This message already created SO-000914.” The link is written in the same commit as the order, and the database will not let two messages claim one.
03
Change Orders and Cancellations
An X12 purchase order carries a code saying what it is: a new order, a change to one you already have, a cancellation, a replacement.
SM Space reads that code and refuses anything that is not a new order, by name. PO-88213 arrives as purpose 00, a new order, and becomes SO-000914. The same reference comes back as purpose 04, a change — and it is not processed. It is left for a person, with a sentence saying exactly why.
That is a decision, not a gap. The failure this module exists to prevent is precisely this one: your customer amends an order, your system reads the amendment as a fresh order, and you ship twice.
Refusing is the right answer when the alternative is quietly doing the wrong thing.
BEG01 00 new order
- ReferencePO-88213
- ResultSO-000914 created
✓ processed
BEG01 04 change
- ReferencePO-88213 the same order
- Resultnothing created parked for a person
✗ refused by name
A change treated as a new order is two shipments.
Cancellations (01) and replacements (05) are refused the same way.
04
Errors That Name the Line
A file that fails validation usually produces “invalid document”. Then somebody opens a 4,000-line text file and starts counting.
SM Space says where. The message names the segment, the position of the element inside it, and the line number in the file — segment PO1, line 14, element 07, value “SKU-99999”, no cross-reference for this partner.
The original file is kept exactly as it arrived, so there is something to check the message against — and something to forward to your customer’s implementer when a mapping argument starts.
Add the missing cross-reference, press reprocess, and you get one sales order — SO-000915 — not a second one.
Error No cross-reference for this partner
- SegmentPO1line 14
- Element position07within that segment
- ValueSKU-99999not known to us
- Original filekept as it arriveddownloadable
- Add the cross-referenceSKU-99999 → your item
- Reprocessthe same guard as the first run
- SO-000915one order, not two
How SM Space EDI software compares
The one-line answers buyers ask for, and then the one that matters more on this page — what is not there.
- Inbound X12 850 Customer purchase orders, read and posted as sales orders.
- 997 acknowledgement Sent back per functional group, saying accepted, accepted with errors, or rejected.
- How files arrive A folder SM Space watches and sweeps on a timer.
- Trading partner identification From the sender ID in the file’s own envelope. An unknown sender is refused, never invented.
- Part-number cross-reference Your customer’s codes mapped to yours, per partner or across the company.
- Duplicate prevention Three kinds, three separate defences.
- Reprocessing Fix the cause and re-run, without creating a second order.
- The original file Kept exactly as it arrived, and downloadable.
- Mapping preview See how a file will land before it lands. It writes nothing.
- Test messages A file flagged as a test is recorded and creates nothing.
- Cloud Runs in a web browser, nothing to install.
What it does not do, today. SM Space takes inbound X12 850 purchase orders from customers and sends a 997 acknowledgement back. Other document types and outbound documents are not available yet — no 855 acknowledgement, no 856 ship notice, no 810 invoice, and no sending purchase orders out to your own suppliers. Files arrive through a watched folder; there is no built-in SFTP or AS2 connection. And a 997 is not an 855: it says your file arrived and parsed, not that we accept your order.
How it fits with the rest of SM Space
SM Space EDI is a layer around the modules you already have, not a module beside them.
- A customer’s X12 850 — dropped in a watched folder into
- Their part numbers — cross-referenced to yours into
- Their sender ID — matched to a trading partner into
- writes Sales & invoicing — the draft order, in your own numbering series
- writes Customer & supplier records — the customer it belongs to
- writes Inventory & accounting — reached the ordinary way, once it is confirmed
The sales order an EDI file creates is an ordinary sales order. It sits in sales and invoicing alongside the typed ones, in the same numbering series. Confirm it and it reserves stock in inventory management, goes through approval if your rules say so, gets picked and delivered, and invoices into the ledger in accounting and finance — because it is a sales order, not an EDI record pretending to be one. Nobody has to learn a second screen, and nobody has to re-key anything.
The trading partner record points at the customer you already have in customer and supplier records. EDI adds their sender ID and their part numbers to it, rather than starting a second list of customers.
Who this EDI software is for
Companies of roughly 20 to 500 people where a large customer has said they will only send orders electronically from now on, and you would rather not re-key them or buy a separate EDI service to sit beside your ERP. SM Space is a cloud ERP system: it runs in a web browser, with nothing to install.
Today this handles inbound customer purchase orders. If you need to send invoices or ship notices electronically, talk to us about timing.
Frequently asked questions
- What does SM Space EDI do?
- It takes purchase orders your customers send electronically and turns them into sales orders, without anybody re-keying them. A customer’s X12 850 arrives, SM Space works out who sent it, maps their part numbers to yours, and creates a draft sales order in your normal numbering series. It sends back a 997 acknowledgement and keeps the original file.
- Which EDI documents does it support?
- One, in one direction: the inbound X12 850 purchase order, with a 997 functional acknowledgement sent back. The 855 acknowledgement, the 856 ship notice and the 810 invoice are not available yet, and neither is sending purchase orders out to your own suppliers. If your customer’s mandate covers those, tell us before you buy anything.
- How do files reach the system?
- Through a folder SM Space watches. A background sweep picks up whatever is in it, records each document, and moves the file to an archive folder rather than deleting it. Some customers deliver through their own EDI network service and some drop the file into a shared location directly — SM Space reads the folder either way. There is no built-in SFTP or AS2 connection yet.
- What happens if the same order arrives twice?
- You get one sales order. SM Space fingerprints the order itself rather than the envelope around it, so an identical order resent in a fresh envelope is recognised and not created again — and the database enforces that, so two background processes reading the folder at the same moment cannot both slip one through. If the same order turns up inside two different files, it is parked for a person rather than posted.
- What if a file is rejected — do we lose the order?
- No. The original file is kept exactly as it arrived, and the failure says where it broke: the segment, the position of the element inside it and the line number, with the value that caused it. Fix the cause — usually a part number with no cross-reference — press reprocess, and you get exactly one sales order. Reprocessing something that already posted is refused by name.
- Do we need an EDI provider or VAN?
- Not one of ours — SM Space reads a folder, so what puts the file there is up to you and your customer. Some customers deliver through their own EDI network service; some drop files into a shared location you agree between you. Either works. What SM Space does not do yet is connect out over SFTP or AS2 itself, so the delivery arrangement is something to settle with your customer.
Take your customer’s EDI orders without re-keying them.
Book a 30-minute demo and we’ll run one of your customer’s own files through it.
Book a 30-minute demo