AI Purchase Order Entry for Indian Manufacturers

In many Indian manufacturing businesses, orders arrive as PDFs. A distributor or OEM emails a purchase order, someone in the sales office opens it, and types each line into Tally or the ERP: customer code, item, quantity, rate, delivery date. With 30 or 40 POs a day in different formats, that's a full-time job, and a typo in a quantity becomes a wrong dispatch.

This is one of the most practical uses of AI in a factory office, and one of the easiest to get wrong if you treat it as fully automatic.

How extraction works

Current AI models can read a PDF and return structured data. Using Anthropic's API as an example, its documentation says PDFs are processed page by page as images alongside their text, so the model can read tables, stamps and scanned pages, not only typed text. Its structured outputs feature constrains the response to a schema you define, such as:

• buyer name, GSTIN and PO number
• PO date and delivery date
• line items: buyer's item code, description, quantity, unit, rate
• delivery address and terms

The same documentation is honest about limits: output can still fail to match the schema in some cases, such as refusals or responses cut off by length. So your code checks every result before using it. Other model providers offer similar features. The design below doesn't depend on which one you pick.

SKU matching is the hard part

Reading the PDF is the easy half. The hard half is mapping what the buyer wrote to what you sell. The buyer's PO says "MS Pipe 25NB Class B 6m". Your item master says "PIPE-MS-025-B-6000". Some buyers use their own item codes, and others describe the same item three different ways.

What works:

• A mapping table of each buyer's item codes and descriptions to your SKUs, built from past orders.
• Exact matches from the table first. The model suggests a match only when there's no entry, and that suggestion always goes to a person.
• Each confirmed match is saved to the table, so the same line is automatic next time.

After a few weeks, most lines from regular buyers match from the table without any guessing.

Rules and the review screen

Keep a person in the loop, and make their job quick. Every extracted PO goes to a review screen showing the PDF next to the draft order, with problems highlighted:

• items not in the mapping table
• rates that differ from the buyer's price list
• quantities far outside that buyer's usual range
• a PO number you've already processed
• missing GSTIN or a delivery date in the past

Clean POs take a few seconds to approve. The person spends their time on the lines that need judgment, which is the point.

Posting without duplicates

Approved orders go to Tally or your ERP through the same queue as any other order, with the PO number as a unique key. If the same PO is emailed twice, or someone forwards it again, the second copy is caught at review instead of becoming a second order. Our post on connecting custom software to Tally covers the posting side, and production patterns for AI integration covers logging, retries and cost control.

What to measure

In the first month, track:

Build or buy

Off-the-shelf document parsers handle extraction well. The value for a manufacturer is usually in the matching, the rules and the connection to your own accounts, which are specific to your business. If a SaaS tool lets you own the mapping table and post cleanly to your system, try it first. If not, a small custom service around a model API is a few weeks of work, and you keep control of your data.

Start with your three biggest buyers. Their POs are the most regular, and they'll show you quickly whether it saves time.