Answer
Can one system handle both EDI and PDF documents?
Updated July 2026 · by the DynamoDocs team
The short answer
Yes, and it is worth insisting on. Most teams run an EDI translator for the partners who mandate it and a separate capture tool for everyone else, which means two sets of rules, two ERP mappings, and two queues to watch. DynamoDocs reads EDI X12 and PDF, email, and scanned documents into the same queue, validates them the same way, and posts them through the same ERP mapping.
Why most companies end up with two systems
The two channels arrive from different vendors. EDI came from a translator or a VAN, bought by IT because a large customer demanded it. Capture came later, bought by finance because everyone else emails a PDF. Neither vendor sells the other half well, so the split hardens, and the ERP ends up with two separate integrations writing to it.
What the split actually costs
A tolerance you change for matching has to be changed twice. A new GL rule has to be added twice. An approval threshold applies in one system and not the other. Worst of all, the same order arriving as both an EDI 850 and an emailed PDF confirmation looks like two orders, because neither system can see the other's documents. The duplicate check has nothing to compare against.
Is EDI just another file format?
As intake, largely yes: an X12 file is one more thing to parse, alongside PDF, Excel, images, and structured e-documents like UBL/Peppol, Factur-X, and cXML. But EDI is the only channel that obliges you to reply. A PDF invoice creates no duty to send anything back; an 850 usually requires a 997 immediately and an 855 inside a stated window, and missing either is a chargeback. That outbound obligation is the part a capture tool cannot bolt on.
One queue, one set of rules
In DynamoDocs an EDI order and an emailed PDF order become the same kind of record. The same validation runs, the same PO matching and duplicate detection apply across both, the same field mapping posts them to your ERP, and the same review queue holds whatever needs a person. The channel a document arrived on is recorded on it, and otherwise stops mattering.
You keep your existing plumbing
This is not a rip-and-replace of your EDI setup. DynamoDocs connects over SFTP, over AS2 directly where a partner offers it, or by reading a folder your VAN client already writes to, so an SPS Commerce, Cleo, or TrueCommerce setup keeps doing exactly what it does now. Whether direct connection is an option is each partner's call; many large partners exchange only through a VAN, and that mode is fully supported. Changing transport later does not change any of your documents or rules.
Related questions
Do we have to drop our VAN?
No. A VAN client writing to a folder is a supported transport, and for partners who only exchange through a VAN it is the right one. Direct SFTP or AS2 is used where a partner offers it. That is the partner's decision; neither side's software is the constraint.
Does an EDI document cost more to process?
No. EDI documents count toward your plan the same as any other document, and there is no separate EDI licence. Connecting each trading partner is scoped as implementation work.
What if a partner sends the order by EDI but the change by email?
Both land in the same queue against the same order, which is the point. A change arriving on a different channel from the original is exactly the case a two-system setup misses.
Is DynamoDocs certified with trading partners?
No. No trading partner has certified DynamoDocs, and every partner runs its own test cycle regardless of which vendor you use; expect two to four rounds. Because each partner's implementation guide is configuration here, each round is a settings change.
Go deeper
See it on your documents
Bring a real invoice, PO, or RFQ and watch DynamoDocs take it from inbox to posted in your ERP in about 30 minutes.
More answers