Dynamics GP loads purchase orders through eConnect, using the taPoHdr and taPoLine nodes, with Integration Manager or SmartConnect sitting on top and reading a CSV or Excel file. All of them want structured rows. None of them reads a PDF. PurchaseOrders reads the purchase order PDF, scan, or photo and returns the header fields and the full line-item table as Excel, CSV, or JSON, so the file your integration picks up is typed by a machine instead of a person. Upload a real purchase order below.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
GP has solid integration machinery. eConnect runs the same validation the screen does, Integration Manager and SmartConnect schedule recurring loads, and the error log tells you exactly which row failed. What none of it does is read the document the order arrived on, which is where the work actually is.
Integration Manager and SmartConnect source from text files, spreadsheets, and ODBC queries. When the order is a customer PDF in the purchasing mailbox or a scan of a mailed document, somebody reads one window and types into another before any integration runs.
A purchase order does not load as a single row. The header maps to taPoHdr and every line to taPoLine, so keying one order by hand means keeping two files consistent, matched on PO number, with no mistakes in either.
If you leave ORD out of taPoLine, eConnect reads a repeated item number as an update to the existing line rather than a new one, so a five-line order silently arrives as three. Nothing errors. You find it during a receipt, or worse, during an audit.
eConnect requires TAXAMNT on taPoHdr and validates it against the sum of line tax plus related freight and miscellaneous tax. A header figure that does not tie to the lines rejects the whole document, and hand-keyed batches produce exactly that kind of mismatch.
GP keeps index tables, next-number sequences, and distribution records in step with the purchase order tables. Writing straight to POP10100 and POP10110 leaves records the application will not open properly, so every load has to go through the supported path.
A quarter of accumulated customer POs, a cutover from a legacy purchasing system, or a newly acquired division all land at once. The eConnect side of that load takes minutes. The data-entry side takes weeks of somebody's time.
PurchaseOrders is the capture step in front of eConnect, Integration Manager, or SmartConnect. It is not a GP connector and it does not run inside GP. You give it a purchase order document. It gives you back clean, field-level data that you map to the nodes your integration already uses, then you load it with the tooling you have today.
A digital PDF from a customer ERP, a scan of a mailed order, or a phone photo of a paper PO. All go through the same extraction, with no per-supplier template to build first and nothing to configure per layout.
PO number, vendor, buyer, ship-to and bill-to, document date, required date, payment terms, currency, and the line grid: item number, vendor item, description, quantity ordered, unit of measure, unit cost, and extended cost, captured across page breaks.
Output is one row per line item with consistent headers, which is the shape Integration Manager and SmartConnect want. Map your columns once to taPoHdr and taPoLine, and every later batch drops into the same mapping.
Pull the same extraction as JSON through our API and feed whatever already talks to GP, whether that is a SmartConnect ODBC source, a custom eConnect service, or a script that assembles the POPTransactionType document itself.
Upload a stack of orders at once rather than one at a time. That is what turns an initial load or a quarter of accumulated emailed POs into a same-day job instead of a staffing problem.
Captured fields are shown on screen so you can correct an odd value before you export. Fixing a quantity here costs seconds; fixing it after a posted receipt costs a good deal more.
Every supported route ends at eConnect. You can call it directly, assembling a POPTransactionType document with a taPoHdr node and one taPoLine node per line, or you can let Integration Manager or SmartConnect do it, pointing them at a CSV, an Excel file, or an ODBC source. Either way GP validates the document the same way the Purchase Order Entry screen would, then writes it to POP10100 and POP10110, whose structure and join keys are laid out in Dynamics GP purchase order tables. The question is where the CSV comes from. If the answer today is a person reading a PDF, this tool replaces that step.
To be plain about the boundary: PurchaseOrders extracts purchase order data from documents into a structured file. It is not a Dynamics GP connector, it does not install in GP, it does not call eConnect for you, it does not write to POP tables, and it does not create, approve, receive, or match purchase orders. Those all stay in GP. We remove the typing that happens before the load, and nothing else.
GP shops running an initial load from a legacy purchasing system use it to build the migration file. Distributors whose customers send POs as PDFs use it so those orders reach GP the same day they arrive. Teams wiring the purchasing mailbox to SmartConnect use the purchase order API so the integration receives JSON rather than an attachment. The purchase order PDF to Excel converter is the quickest way to see the output shape, row-level accuracy on long orders is covered in purchase order line item extraction, and a backlog clears through bulk purchase order upload. The general load path across systems is in how to import purchase orders to an ERP, and teams already planning the move off GP can compare purchase order to Business Central.
All three end at the same place, an order sitting in GP Purchase Order Processing. They differ in what happens before the load.
| What matters | Manual keying into GP | Template OCR tools | PurchaseOrders AI |
|---|---|---|---|
| Setup per supplier layout | None, but slow forever | Build a template each | None, any layout |
| Mixed PDF, scan, photo | Handled by a person | Often breaks | Handled automatically |
| Line-item capture | Error-prone by hand | Varies by template | Full line-item tables |
| Time per purchase order | 5 to 10 minutes | 1 to 3 minutes | Under 10 seconds |
| Output shape | Typed straight into GP | Needs cleanup | Row per line, ready to map |
| Rejected documents to chase | Typos drive most of them | Some | Fewer, data is reviewed first |
| Cost per PO at volume | High manual labor | Per-page plus setup | Under $2 |
PurchaseOrders.io extracts purchase order data into Excel, CSV, JSON, or an API response that you map to the eConnect taPoHdr and taPoLine nodes. It is not a Dynamics GP connector, does not install in GP, does not call eConnect or run Integration Manager for you, does not write to POP tables, and does not create, approve, receive, or match purchase orders. Microsoft, Dynamics GP, and Dynamics 365 Business Central are trademarks of Microsoft Corporation; this page is not affiliated with or endorsed by Microsoft. Manual cost reflects published estimates of $15 to $40 to fully process a purchase order by hand.
No templates to build, no changes inside GP.
Drag in PDFs, scans, or photos, one at a time or a whole batch pulled from the purchasing mailbox.
Tip: Mixed suppliers and file types in the same upload are fine.
The AI reads each order and returns the header fields and the complete line-item table in seconds.
Tip: Check the captured values on screen before you export, not after eConnect rejects the document.
Download Excel or CSV, map the columns to your Integration Manager or SmartConnect source, and run the integration, or pull JSON via the API and build the eConnect document from your own code.
Through eConnect, either directly or via a tool built on it. You assemble a POPTransactionType document with a taPoHdr node for the header and a taPoLine node for each line, or you point Integration Manager or SmartConnect at a CSV, Excel, or ODBC source and let it build the document. GP then validates and writes the order exactly as if it had been keyed on the Purchase Order Entry screen.
No. Integration Manager sources from text files, spreadsheets, and ODBC queries, not from documents. A PDF or scanned purchase order has to be converted into rows first. That conversion is what PurchaseOrders does: it reads the document and returns the header fields and line items as a CSV or Excel file Integration Manager can pick up.
taPoHdr creates the purchase order header and taPoLine creates each line, both inside a POPTransactionType document. taPopIvcTaxInsert handles tax detail where needed. The header requires TAXAMNT, and eConnect validates that value against the sum of line tax plus related freight and miscellaneous tax, so the header total has to reconcile to the lines.
Almost always because ORD, the line sequence number, was left out of taPoLine. Without it, eConnect treats a repeated item number as an update to the existing line rather than a new line, so duplicate items collapse into one. Supply ORD explicitly. GP increments it by 16384 per line, so 16384, 32768, and 49152 are the first three values.
POP10100 for the header and POP10110 for the lines while the order is active. When it is closed or canceled GP moves it to POP30100 and POP30110. You should not insert into these tables directly, because GP maintains index tables, next-number sequences, and distribution records alongside them that a raw insert would leave inconsistent.
No, and we would rather say so plainly. It reads purchase order documents and returns structured data. It does not install in GP, does not call eConnect, does not run Integration Manager or SmartConnect, does not write to POP tables, and does not create, approve, receive, or match orders. You keep using GP's own integration tooling; we just remove the typing in front of it.
Yes. The AI handles scans and phone photos, not only digital PDFs, and returns the same structured fields. That matters for GP shops because a good share of customer and supplier orders still arrive as scans or faxes, which template-based OCR tools tend to miss or mangle.
Yes, and arguably more so. Extraction produces a plain CSV of header and line data, so the same file feeds a GP integration today and a Business Central configuration package later. The document-reading step does not change when the target system does. Business Central specifics are on our purchase order to Business Central page.
Microsoft ends product support and updates for Dynamics GP on December 31, 2029, with security patches continuing until April 30, 2031. New subscription sales stopped on April 1, 2026. Existing installations keep running until then, which is why many GP shops are still investing in reducing manual purchasing data entry rather than waiting for a migration.
Pricing is per document with volume tiers, and at volume the cost works out under $2 per purchase order. You can try it on a real order before paying anything. Compare that to published estimates of $15 to $40 to process a purchase order fully by hand, most of which is the keying this removes.
The same capture step for Business Central.
The general ERP load path.
Extract PO data to JSON via REST API.
How the line-item table is captured.
Clear a migration backlog in batches.
See the output shape in one upload.
