What actually happens to a PO

From the email landing in your inbox to the sales order in Acumatica. Six steps, same process on every order, whether anyone at your shop is thinking about it that day or not.

01

PO email lands in a shared inbox

Your customers send POs however they send them: PDF attachments, Excel files, or just line items typed in the email body. They all go to one shared inbox that the system watches.

02

Extraction pulls the order details

AI reads the PO wherever the data lives—inside a PDF, across Excel columns, or in the email text. Line items, quantities, ship-to address, PO number, and requested delivery date all get pulled into structured fields.

03

Customer part numbers match to your SKUs

Your customers order by their own part numbers, not yours. The cross-reference table maps each customer part number to your internal SKU. If a part number isn't in the table yet, the order gets flagged for review.

04

UOM and pricing rules are applied

A customer writes 'box of 100' but you sell each. The system converts the quantity using your UOM rules. Contract pricing, volume price breaks, and special customer rates are applied per line. Anything that doesn't match a rule gets flagged.

05

Exceptions go to a review queue

Orders with missing SKU matches, ambiguous quantities, pricing questions, or unclear ship-to addresses wait for a person. Your team sees what was flagged, why it was flagged, and fixes it in one place before it moves forward.

06

Sales order is created in Acumatica

Clean orders that passed all the checks get created as sales orders in Acumatica through the REST API, with the source PO attached as a document. Orders that were reviewed and approved post the same way once you clear them.

What the system handles

  • PO extraction from email, PDF, or Excel
  • Customer part number to SKU cross-reference
  • UOM conversion rules applied per line
  • Customer-specific pricing and volume breaks
  • Exception flagging for missing matches or ambiguous data
  • Sales orders posted to Acumatica with the source PO attached

Three things stay yours, on purpose.

Automating the extraction and the matching is the point. Automating your judgment is not.

You approve the rules

The cross-reference table, the UOM conversions, the pricing rules—those are yours to set and change. The system applies them, but you decide what they say.

You review the exceptions

Nothing unclear reaches Acumatica on a guess. If a customer part number isn't in the table or a quantity doesn't match a UOM rule, the order waits for you to look at it and decide what it should be.

You decide what auto-posts

Some customers send clean POs every time. Some never do. You can set certain customers or certain order types to auto-post when they pass all checks, and hold others for review no matter what.

Runs on the Acumatica you already have.

No new ERP to learn, no middleware to maintain, no data sync that might fall behind. The system uses an API user in your Acumatica instance—one you create, with permissions you set, and that you can revoke any time in one click without calling me.

Built with Make and AI models. The orchestration runs in Make, the extraction and matching run through API calls to language models, and the output posts through the Acumatica REST API. Simple enough to explain, reliable enough to trust with real orders.

What you provide

  • A shared inbox where customer PO emails land
  • An Acumatica API user with sales order creation permissions
  • Your customer part number to SKU cross-reference table
  • UOM conversion rules and customer pricing tables
  • Access to review and approve flagged exceptions

Does that match how POs come in at your shop?

Genuinely asking. 15 minutes, and if I have a step wrong or there's a piece I'm missing, I'd rather hear it from you now than find out on your customers' orders.