Email and PDF Orders to Your ERP: What to Automate and What to Review

TL;DR

• A customer's purchase order becomes a sales order in your ERP. Define where automation stops: extracted fields, a reviewable quote or an order authorized for fulfillment.
• Treat extraction confidence and business validity separately. A correctly read price can still conflict with the applicable agreement, and a plausible product match can still be wrong.
• Route unknown items, conflicting instructions and revised documents to a named reviewer. Preserve what the customer sent alongside the corrected and accepted values.
• Identify the business request as well as the email. A forwarded attachment, a revised PDF and a second delivery against the same purchase order need different handling.
• Pilot complete orders, including failures, before allowing unattended processing. Compare review time and downstream corrections, not just how many fields the software fills.

Let customers keep emailing, without treating every attachment as an order

For example, suppose a packaging distributor receives customer purchase orders by email. An order administrator opens the attachment, identifies the account, translates customer item codes into the distributor's catalogue, checks the terms and enters a sales order. Customers are comfortable with email and are not ready to move to a portal.

The distributor and the examples below are hypothetical, not Caemcore client results. The objective is to remove repeated entry while preserving the decisions the administrator currently makes.

Here, the customer's purchase order is an incoming buying request. The seller creates a sales order in its ERP, the system used for order handling, stock and accounting. This is a different workflow from processing supplier invoices or issuing purchase orders to your own suppliers.

Start with one ordinary order and one the administrator had to correct. Ask them to explain each check between opening the email and confirming the order. Those checks define the work, whether a product, an integration or a person performs it.

A customer-facing portal is another option, covered in our B2B ordering portal and ERP guide. The question here is what you can change on your side when the customer continues sending documents.

Check what your ERP and existing products already offer

Email-to-order processing does not automatically require a new application. Give existing suppliers the same sample documents and expected ERP outcomes before commissioning custom development.

Microsoft's Business Central Sales Order Agent processes sales requests from a designated mailbox and can analyze PDF attachments, identify customers and prepare quotes and orders. Microsoft documents review and approval of outgoing messages by designated users. This is an existing ERP capability to evaluate, not proof that it handles every installation's extensions or commercial rules.

Its setup documentation requires a Microsoft 365 mailbox and configured consumption-based billing. It also describes a configuration that pauses for quote review when custom pricing or other fields need human work. Check availability, supported languages, permissions and the proposed configuration in your environment.

Specialist order-entry products are another route. Conexiom advertises document extraction, ERP-based validation and conversion of incoming purchase orders into sales orders. Evaluate its actual connection to your ERP and your exceptions. A vendor's published capabilities are not a hands-on comparison or evidence of performance on your documents.

A configured workflow may also be enough. AI Builder's document-processing action in Power Automate returns extracted fields and table cells, with confidence values, for later steps. That supplies part of the process; the customer mapping, review queue and supported ERP write still need implementation.

Ask each supplier to separate what already works, what needs configuration and what remains unsupported. A requirement that fails after one setup attempt is not yet a verified product limit.

Choose the stopping point before connecting the mailbox

Distinguish three outcomes: an extracted document, a checked ERP record and an order accepted for fulfillment. They should not share one status called processed.

For a first release, consider preparing a reviewable record while retaining the existing release decision. Establish what creating that record actually does in your ERP. Does it affect allocation, planning, customer communication or another integration? A record labelled draft is not enough evidence that it has no operational effects.

There is a concrete example in Business Central's agent overview: the agent first creates a sales quote, which Microsoft says does not affect planning, reservations, availability or cash-flow forecasts. Configuration determines whether that quote is later converted into an order. That behavior belongs to this product, not every ERP's draft status.

For the hypothetical distributor, let the intake record retain the email, original attachment, extracted values, proposed mappings and review decisions. Keep the ERP responsible for the applicable commercial records and the accepted sales order. A receipt acknowledgment should not promise stock or delivery merely because the PDF was read.

What can pass automatically, and what needs review?

Use the following as a proposed decision sheet for automatic draft creation, not automatic shipment authorization. All required checks must pass. A row passing does not cancel a failure elsewhere, and the business must approve the rules for its own accounts and products.

Let the software suggest a mapping without granting it authority to establish one. For example, a close description match can help a reviewer find a product, but it should not silently create a permanent customer-item reference. Save approved mappings under a named owner and test later changes.

Check the whole document, including continuation pages, delivery instructions and attachments referenced in the message. A high score on the rows that were extracted says nothing about a row that never reached the proposed order. Keep unclear or unsupported documents visible in the queue rather than dropping them from the totals.

A perfectly read PDF can contain the wrong price

Hypothetical example. An established customer sends a purchase order for eight cartons of tape. Its approved item mapping says each carton contains six rolls. The PDF states $2.20 per roll and a merchandise total of $105.60. The ERP's applicable agreement in this example now gives $2.50 per roll. Tax and freight are excluded from the illustration.

The quantity is 8 × 6 = 48 rolls. At the document price, 48 × $2.20 = $105.60. At the ERP agreement price, 48 × $2.50 = $120, a difference of $14.40.

The reader could extract every character correctly. The unresolved question is commercial: should the distributor honor the requested price, ask the customer to accept the current price, or reject the request? That requires the approved policy or an authorized decision, not a more confident text prediction.

Microsoft's Document Intelligence guidance distinguishes field, word and other confidence measurements and notes that not every field has a score. It also recommends evaluating representative document variations. Treat these scores as evidence about extraction, not confirmation that an entire order is commercially valid.

For this example, send the price difference to the account's reviewer. Show the original $2.20, the applicable $2.50, the quantity conversion and the source of the ERP terms. Preserve the decision and any customer response with the intake record. Do not quietly overwrite the requested price and claim the customer agreed.

If the carton conversion were unknown, hold the quantity too. Matching the grand total would not resolve whether the customer meant rolls, cartons or another packaging unit.

Give the reviewer the disagreement, not another blank form

The review screen should explain why the request stopped. Display the original page or relevant email text beside the proposed ERP fields, with the customer, item mapping and current terms available for comparison.

For the tape example, the reviewer needs a price decision. They should not have to retype the order simply to reach it. For an ambiguous product, show the proposed candidates without selecting a substitute automatically. A missing delivery instruction should remain a specific unresolved item, not a generic error.

Assign an owner and show whether someone else is already handling the request. Record corrections, who approved them and the document version used. A reply from the customer must attach to that investigation rather than start another independent order.

Before submission, recheck facts that may have changed while the request was waiting. A reviewer approving a quantity yesterday does not establish today's availability. Decide which checks need repeating and which earlier approvals remain valid.

Separate a repeated email from a revised purchase order

Keep both technical and business references. An email identifier and file fingerprint help trace what arrived; they do not fully define the customer's intent.

A customer can send the same order in a new message, forward it through a salesperson or attach a fresh scan. Conversely, the same purchase-order number may support several legitimate releases. Define the business identity using the account, purchase-order reference and any revision or release identifiers your process actually needs.

When a corrected PDF arrives, compare it with the version already handled. If nothing has been committed, replace the proposed version through the agreed review process. If an order already exists, treat the document as a potential amendment. Do not create another order or overwrite accepted work simply because the attachment is newer.

Coordinate submission so two workers cannot independently create the same order. The Microsoft Retry pattern explains a separate failure: a remote operation can succeed even when its response is lost. Retrying without accounting for that outcome can repeat its effects.

Require the integration to retain a submission reference and recover the existing ERP result through supported operations before attempting a new creation. When the outcome cannot be established, show it as uncertain and assign investigation. Do not relabel uncertainty as failure and invite another order.

Our guide to connecting business systems without replacing everything covers broader ownership and recovery decisions. Here, those controls must also distinguish document versions and customer replies.

Keep document content separate from permission to act

Treat incoming files as untrusted input. OWASP's file-upload guidance recommends validating permitted file types and size, restricting access and applying appropriate scanning. Store order documents privately and give operators access only to the accounts they handle. Do not send confidential samples to an unapproved public testing service.

If a language model interprets emails or PDFs, text inside them must not change the integration's authority. OWASP identifies email content and attachments as possible sources of indirect prompt injection and recommends tool-call validation and least-privilege access. Enforce allowed ERP operations and approval rules outside the model; a document cannot authorize bypassing them.

Test one order pack with deliberate exceptions

Use synthetic documents in a non-production environment, with customer messages redirected to test recipients and no path to live fulfillment. Give the ERP partner, product supplier and proposed developer the same expected results. Label mocked ERP responses; they do not prove that the real connection works.

1. Complete the ordinary request. Use an agreed-price version of the tape order, with a second item on another page. Trace every line, the account, delivery location and units into the reviewable ERP record. Confirm that no unapproved release or customer commitment follows.
2. Introduce a commercial disagreement. Use the $2.20 version, then an unknown item code. Both should stop for the appropriate reason. Add an email instruction that conflicts with the PDF quantity and check that the disagreement is visible rather than silently resolved.
3. Resend, revise and submit concurrently. Send the same business request through a different message, then a changed version. Have two test operators attempt submission. Verify one intended order for the original request and an explicit decision for the amendment, with both documents retained.
4. Interrupt ERP processing. Lose the response after a successful creation. Separately reject one line while others have been accepted by the interface. Recover the first result without duplication; prevent an incomplete second record from being treated as a complete order. Account for each proposed line and the actual ERP state.
5. Hand the exception to another person. Give a reviewer a stalled request without coaching. They must find what arrived, what was decided, whether an ERP record exists and what remains to do. After an outage, verify that requests already handled manually are reconciled before the backlog resumes.

A deliberate hold is a successful test when review is the expected outcome. Record passed, failed and untested results against the exact configuration. These checks are a workflow acceptance exercise, not a complete security assessment.

Pilot the order outcome, not the extraction percentage

Begin with a bounded mailbox or folder, customer group, product range and ERP destination. Use representative documents under approved data-handling arrangements. Include changed layouts, poor scans, long orders and genuine exceptions, not only the cleanest samples.

Start by comparing proposed records with independently checked expected results, without releasing orders. Keep some documents out of configuration and tuning so the evaluation is not just a replay of examples used to set the system up.

Measure correctly prepared complete orders, cases requiring intervention, missing lines, incorrect automatic passes and time spent reviewing or correcting work. State the denominator: all incoming requests, eligible requests or extracted fields. A good field-level percentage can conceal a wrong account on an otherwise accurate order.

Compare the administrator's full task before and after, including exception work and downstream corrections. Time no longer spent typing may become time spent reviewing; it is not automatically a reduction in payroll spending. A clean pilot narrows uncertainty but does not prove every future document will be safe.

Agree who may pause processing, who owns the queue and how manually handled requests are recorded during an interruption. Expand unattended steps only for the combinations the business has accepted, and keep new or changed cases on a review path.

What would justify custom development?

Commission custom work when an essential part of the intake or review process remains unsupported after testing the smaller routes. A possible gap is matching one customer's document across several internal records, with account-specific decisions that the evaluated product cannot represent. Name the gap and the evidence before requesting a build.

The custom scope might be a review workspace or an ERP connector around an existing extraction service. It need not include a new document-recognition engine, customer portal or replacement ERP. If a ready-made configuration passes the required cases, compare its operating cost rather than rebuilding its features.

Request separate estimates for mailbox intake, extraction setup, reference-data preparation, review handling, ERP integration, testing and rollout. Include recurring document or usage charges, vendor access, support and the remaining operator workload. Specify who maintains mappings when a customer changes its codes or document layout.

Keep manual review where the volume or uncertainty makes it the sensible choice. Automating a reliable draft can be a complete first project. The useful result is an order administrator who can resolve exceptions without entering the same information again, with every incoming request accounted for.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Not sure what you need? A 30-minute call, free: what the task actually is, whether it needs building or an off-the-shelf tool covers it, a range and a timeline. You get that whether we work together or not.

FAQ

Can salespeople forward customer emails into the order mailbox?

Yes, but test how the chosen product identifies the customer. Business Central's Sales Order Agent uses the forwarder's address rather than the original sender's address, according to Microsoft's documentation. Provide an explicit way to select the correct customer for that request. Do not permanently associate a salesperson's address with one customer when they forward orders for several accounts.

Can we process different languages and number formats?

Evaluate each required language, document layout and regional format with representative examples. Confirm the chosen product's documented support instead of assuming that a successful English example covers everything. Preserve currency and units explicitly, and flag ambiguous dates or decimal separators. Translating a product description does not establish which catalogue item the customer intended.

What if the ERP has no suitable API?

Ask the ERP vendor about supported imports, extensions or an existing order-entry module. A prepared import file can still remove typing, provided rejected rows are visible and operators can trace the resulting records. Document the delay and any manual release step. Do not bypass the ERP's controls through direct database writes merely to make the transfer automatic.

Can email orders run alongside a portal or structured ordering channel?

Yes. Keep channels that already work, but give the intake process a way to recognize the same business request arriving through more than one route. Preserve each channel's reference and the shared customer or order relationship. Test a customer who submits through the portal and then emails the purchase order as supporting documentation, rather than assuming that the attachment requests another order.

Do reviewer corrections automatically improve future extraction?

Do not assume so. Ask which corrections update one request, which create approved mappings and which enter a model-training or configuration process. Give each kind of change an owner. Before reusing a correction, test it on other documents and confirm that it does not change the meaning for a different customer, product or layout.

Sources

• Microsoft Learn, Sales Order Agent overview. Checked 16 September 2026.
• Microsoft Learn, Set up Sales Order Agent. Checked 16 September 2026.
• Conexiom, Sales order automation product overview. Checked 16 September 2026.
• Microsoft Learn, Use a document processing model in Power Automate. Checked 16 September 2026.
• Microsoft Learn, Document Intelligence accuracy and confidence. Checked 16 September 2026.
• Microsoft Azure Architecture Center, Retry pattern. Checked 16 September 2026.
• OWASP, File Upload Cheat Sheet. Checked 16 September 2026.
• OWASP, LLM Prompt Injection Prevention Cheat Sheet. Checked 16 September 2026.

Product descriptions were checked on 16 September 2026 using first-party documentation and product pages, not hands-on comparison tests. The packaging distributor, quantities, prices, decision sheet and acceptance exercise are hypothetical editorial examples, not Caemcore client results or universal automation thresholds. Actual behavior must be verified in the proposed ERP environment, subscription and configuration.