A purchase order (PO) from a buyer means far more than just a piece of paper to vendor employees.
That single document brings a surprisingly heavy workload.
Why does this happen?
And how did we work through this problem?
The Burden of POs on Vendor Staff
A single purchase order brought three headaches to employees:
- Format confusion
- Repetitive manual work
- Time pressure
Inconsistent formats and incomplete data
Every buyer had different PO templates—PDF, Excel, email, you name it.
Date formats and currency notations varied, and often delivery dates or size details were missing.
Repetitive manual entry and revision management
Each PO had to be keyed directly into the ERP. The more items, the higher the chance of errors.
And whenever a buyer sent a revised PO, staff had to manually cross-check against the old one.
Time pressure and risks
Buyers demanded quick confirmation and replies.
Input and verification had to be completed within a short window, and a single mistake could mean delivery delays or claims.
To solve this, we began developing a PO Mapping feature in Monolis.
Introduction—and Limits—of PO Mapping
When we talk about PO mapping, simply put,
it means
“uploading a buyer’s PDF purchase order, extracting the required information,
and saving it into Monolis according to its database schema.”
At first, it seemed simple:
extract key info from PDFs and convert it into ERP format.
The automation reduced manual effort in a noticeable way.
But soon reality hit.
Hardcoding by buyer
Since each buyer’s format was different, we essentially had to code separate rules for each one.
PDF format variability
Even small changes—an added column or a modified header—broke the logic.
That meant rebuilding the entire mapping.
We realized: “This method will be impossible to maintain.”
Turning to AI—And Back to Code
So, we tried AI.
We converted PDFs into text using OCR, then asked a large language model (LLM) to “extract the PO number, items, quantities, and delivery dates.”
Early tests looked promising—much faster than human entry.
But in real use, the problems came out.
Accuracy instability
Numbers were misread as PO IDs, quantities were misinterpreted.
Lack of consistency
Even slight layout changes in the same buyer’s document led to different results.
PDF length issues
Longer documents often caused missing lines or skipped data.
In the end, humans still had to double-check everything—making it even less efficient.
Why 100% Accuracy Matters
PO mapping wasn’t just about “making life easier.”
It was directly tied to ERP data accuracy.
One wrong PO number could disrupt production, shipping, and delivery.
This wasn’t a “close enough” task—it required 100% accuracy.
AI showed potential, but in this area, it wasn’t reliable.
So we drew a new principle:
- Critical accuracy-dependent logic must be coded.
- AI should only support in auxiliary areas (preprocessing, pattern recognition, etc.).
Conclusion
This experience taught us that “automation = AI” isn’t always true.
When 100% accuracy is required, human-coded logic is still the safest choice.
Our team won’t exclude AI altogether.
But we believe the real key is defining the boundary:
What tasks can be left to AI, and what must remain firmly in code?
The PO mapping journey isn’t over yet.
But along the way, we’ve gained stronger principles and experience.
From here, our focus is on building systems that both clients and factory teams can truly rely on.
🔗 Want to Learn More?
- 🌐 Website: https://sije.io/en/solution/monolis
Check out the detailed functions of Monolis.
