AI reads the PO.Fixed rules decide the match.
Every customer PO has to be checked against the quotation before the order is confirmed. Item codes, quantities, amounts. TOTO India now gets that check done by machine: AI reads the PO, fixed rules compare it against the quotation, and the confirmation screen gets a clear answer in seconds.
The problem
The quotation is already in the system. Item codes, quantities, the rate agreed with the party, site details, validity. Then the customer sends a PO, and somebody has to check that this PO matches that quotation before the order is confirmed.
That check takes time, and it is easy to get wrong. POs arrive in every possible shape. A clean PDF. A photo taken on a phone. An Excel sheet exported and cropped at the edges. One item code can be split across two or three lines. OCR mangles item codes that carry special characters. A 10-page PO has terms pages in it, and often a copy of your own quotation attached, so quantities get picked up from the wrong page.
And sometimes the file is simply the wrong one. An old quotation. An invoice. An RFQ. It looks official, it passes, the order is confirmed. Then the wrong material is dispatched, or the order goes out at a rate nobody agreed to.
A wrong PO does not cost you an email. It costs you a dispatch.
What we built
A comparison service that the quotation platform calls the moment somebody tries to confirm an order. It receives the quotation the platform already holds, plus the customer PO. It sends back a status, a short message, a comparison table, and a list of exactly what does not match.
How the work is split is the part worth explaining. AI reads the document. AI never decides. The file is checked for quality first, so a cropped Excel export or a blurred scan is stopped before it can throw up a false mismatch. If the PDF already has selectable text it is read directly, at no OCR cost. OCR runs only on scans. A language model then pulls the page into a fixed format - header, item table, totals, and what kind of document this actually is - and it is instructed never to invent a number.
After that it is plain code. Item codes are grouped and totalled. Quantities have to match exactly. The amount has to match within a set tolerance. Site and validity are raised as warnings, not failures. Run the same two files twice and you get the same answer both times, and for every answer you can point to the rule that gave it.
Inside the system
Reading the PO
- File quality checked first - encrypted files, cropped pages and low-resolution scans stopped before any AI cost
- PDFs that already carry text are read directly. OCR runs only on scans
- Header, item table, totals, taxes and terms pulled into a fixed format
- Document identified as PO, quotation, invoice, RFQ or unknown
- Quotation item codes passed in as hints, so OCR mistakes in a code are corrected instead of guessed
- Page 1 treated as the item table, so an attached quotation cannot supply quantities
Six answers the confirmation screen can get
- Matched - item codes, quantities and amount all agree. Confirm the order
- Wrong PO - this file is not the PO for this quotation
- Mismatched - right kind of document, but the details differ. The table shows which line
- Needs review - not clear enough to decide. Send it to a person
- Poor document quality - the scan cannot be trusted. Ask the party for a better PDF
- Failed - a technical error, not a commercial answer
What changed
No order gets confirmed without the check
The PO has to be checked against the quotation first. What used to depend on how carefully somebody read a PDF at seven in the evening is now a step nobody can skip.
A bad scan is called a bad scan
A cropped Excel export is not a pricing dispute. The system says the file cannot be read and asks for a better one, instead of sending your team to argue over quantities that were never there. This one distinction is most of why people trust the result.
You can see exactly what does not match
When something does not agree, the screen shows the item code and the field - quotation value against PO value. Not a general error message. Your sales and accounts people can see which rule failed, and why.
Same files, same answer, every time
A model reads the document, but fixed rules make the decision. So the answer does not change from one run to the next, and it can be checked again afterwards. A model deciding on its own could never give you that.
How it was built
A separate service with a fixed JSON contract. The quotation platform got the check without a single change to the way it makes quotations.
Other systems we have built near this one
Dealer NetworksDealer quotations priced by rating, approved by rule, synced to SAPRead the case study>
Energy & IndustrialQuotation Approval Application for standard and BTO requirementsRead the case study>
Energy & IndustrialFrom first lead to grid connection, and the warehouse behind itRead the case study>Who checks your POs today?
PO against quotation. Invoice against delivery challan. Test certificate against specification. Anywhere a person has to prove that two documents agree, quickly, right at the end of a process. Tell us how yours is checked today and we will tell you straight which part a machine should decide, and which part it should not.