How Pelangi Spent 40% Less Time on Each Purchase Order

What they achieved

Axrail’s case study on Pelangi says the company spends 40% less time processing each purchase order, and that the manpower requirement for this work is 25% lower over three years. Those two figures are the vendor’s. The AWS Partner Network post that describes the same project, published 17 September 2024, does not print them.

What that AWS post does say is the shape of the change. Pelangi left a manual process for one that was faster and needed less human intervention. Staff moved to other work. The post’s summary is that the company was “achieving more with the same number of human resources.”

Sum Lih Kang, Executive Director, is quoted on the same page. The firm processes “over hundreds of thousands of physical documents annually, including purchase orders, credit notes, and invoices.” Sales coordinators had been typing that pile into the Business Portal. Errors showed up especially on unstructured documents and on documents in more than one language. SmartEye, Axrail’s tool, uses Amazon Textract and Amazon Bedrock to extract and contextualize the data. He says that reduced the coordinators’ manual work of validating and approving documents, and “helped us to reskill 2-3 employees to perform other critical business tasks.”

Keep those sentences apart. Axrail is reporting a time cut per order and a leaner requirement over three years. AWS is reporting the same resources doing more. The director is reporting two or three people moved onto other tasks. None of the pages says the company shrank, and none of them publishes an accuracy rate.

Axrail also says, without a percentage, that better extraction cut the wrong-supply cases and the complaints that manual keying used to cause, and that sales staff now spend that time on sales instead of data entry. That is the vendor’s account of the outcome.

What they do

Pelangi Publishing Group is a Malaysian educational publisher, founded in 1979. Axrail’s case study says a group of young teachers started it. The headquarters are in Malaysia, with publishing offices in Thailand and Indonesia. The books follow the Malaysian, Thai, Indonesian, and Singapore curricula, from kindergarten through pre-university.

The same page says the house produces more than 400 new publications a year, in five languages: English, Bahasa Malaysia, Chinese, Thai, and Bahasa Indonesia. The catalogue behind that is wide. Subjects, levels, series, and versions multiply the SKUs, and the customers run from large city schools to small rural ones. Axrail notes that many of the distributors still work in conventional ways, with a lot of the order still on paper.

The clock is the school year. In the months before a new school season, a high volume of book orders has to clear a short processing window. That is when keying by hand hurts.

The old path was a person reading the purchase order and typing it into the business portal. AWS describes the target pile as thousands of documents, purchase orders and invoices among them, in more than one language. The aim was less manual entry and fewer of the errors that came with it. The director’s quote adds credit notes, and names the Business Portal as the place the coordinators had to input and organise the information.

How they do it

Both public accounts name the same product. Pelangi adopted Axrail.AI’s SmartEye for intelligent document processing.

Axrail’s page is the one that walks the Pelangi documents.

Someone scans the customer’s order. The scanner sends an email, and that mail starts the job. Amazon Textract pulls six things off the page: customer PO, customer id, customer name, ISBN or bookcode, quantity, and sample. The text goes to Amazon Bedrock running Anthropic’s Claude, which turns it into key-value pairs. The order database is filled from that. Pelangi’s admins then review and verify the extraction on a web portal before the order continues.

A diagram on the same Axrail page shows the general case, not a named Pelangi system: a team keying purchase orders into an ERP such as SAP or Navision. The page does not say which ERP Pelangi itself runs. It does say the customer still issues a purchase order in the usual way, and that the platform, rather than a coordinator, carries the data onward. A later line says the ERP is fed automatically. Read that next to step six. Step six is an admin checking the web portal before the order moves on. “Automatically” here means nobody retypes every cell. It does not mean nobody looks.

The AWS post describes SmartEye’s architecture as the product pattern. A document is uploaded to Amazon S3, by hand or in a batch. That upload starts a Lambda function, which calls Amazon Textract to read the page. Textract’s output goes to Amazon Bedrock for entities (names, amounts, dates), language, and meaning. The result is stored in DynamoDB. Lambda also writes a CSV to S3, which a scheduled job can export back to the document system.

On languages, the AWS post is specific. Textract’s own language list, as they cite it, is Latin-script: English, Spanish, Italian, Portuguese, French, and German. Malay and Indonesian are Latin letters too, but they are not that list. For those pages the pattern is raw OCR from Textract, then Claude to find the fields. The authors say Claude 2.1 and Claude 3 did this well on Latin-script Southeast Asian languages. They prefer Claude 3 when the page includes a spreadsheet, a photo, or a diagram, because that model can see the page.

The control worth copying is the one both sources still leave with a person. The director talks about less manual work in validating and approving, not about approval going away. Axrail’s numbered steps end the automatic part at the portal, where an admin verifies the fields before the order continues.

The hard parts

The 40% and the 25% are Axrail’s. They are a vendor case study about this publisher. AWS does not publish them and does not present them as an audit. Quote Axrail if you quote the numbers. Do not put them in a proposal as if they were your own forecast, or Amazon’s measurement of your desk.

Three sentences about people are not one metric. “The same number of human resources” is the AWS summary. “Reskill 2-3 employees” is the director, on that page. “25% lower manpower requirement over three years” is Axrail. A small group can change jobs while a vendor describes a leaner requirement over three years and a blog summarises the firm as doing more without a hiring story. Quote the sentence you mean. Do not add them together.

No accuracy rate is published for Pelangi. Axrail says wrong-supply cases and complaints fell. It does not say by how much. Do not fill the gap with 99%, or with an hours-to-minutes line. The AWS post’s “hours to minutes” remark, and a separate “5 to 2 employees” example, sit in the paragraph about SmartEye’s customers in general, before the Pelangi section. They are not Pelangi measurements.

“Thousands” and “hundreds of thousands” are both on the AWS page, and they are not the same sentence. The project description says Pelangi wanted to streamline thousands of documents, such as purchase orders and invoices. The director says the company processes over hundreds of thousands of physical documents a year, and he includes credit notes. Quote the sentence you mean. Do not merge them into one volume.

Chinese and Thai are not the Latin-script shortcut. The AWS note on this pipeline is about Textract plus Claude for languages written in Latin letters. Pelangi also publishes in Chinese and Thai, and the director names multi-language documents as a place errors already lived. A Latin-only OCR pass will not read those pages. The safe result is a blank and a person, not a guessed ISBN.

The field list is short on purpose. Customer PO, customer id, customer name, ISBN or bookcode, quantity, sample. A title is not an ISBN. A model that “recognises the book” and writes a code the page never showed will send the wrong title to a school. That is the wrong-supply problem the project was meant to shrink.

A sample copy is not a small invoice line. Sample is one of the six fields Axrail names. A free copy that becomes a billed quantity is an ordinary billing error, and the extractor has to be allowed to leave the flag unknown.

The human stays on the approval. Both accounts describe less retyping. Axrail still puts an admin on the portal before the order continues. An unattended write into an ERP is a different system, and it is not what the numbered steps describe.

The school-season pile is the real test. The months before term, a large SKU list, and scans that are not tidy English forms are the job Axrail describes. A demo on ten clean PDFs has not met it.

How a smaller business can copy it

The useful shape, if you publish, distribute, or wholesale, and the purchase order still arrives as a scan or a PDF in an inbox:

A scan or an email lands in one place
        ↓
OCR reads the page. A model proposes the named fields.
        ↓
Missing, conflicting, or unreadable fields are flagged
        ↓
A person compares the fields to the page and approves
        ↓
Only then does the order go to the ERP

Version 1 of that loop never writes the ERP on its own. The first ERP in the build is a stub that rejects a payload with no reviewer.

What the instruction file will make an agent do

The file below is the brief. Hand it to the agent that builds or runs the desk. It is written as orders, with the blanks marked REPLACE.

It will make the agent:

• Refuse to watch the mailbox until you name the reviewer, the scan inbox, and a real customer file and ISBN file.
• Take purchase orders from a scan-to-email mailbox or a folder. One file, one hash, no second order for the same bytes.
• Propose only the named fields. Leave ISBN, bookcode, quantity, and customer id empty when they are not on the page.
• Throw away an ISBN that fails its check digit. Do not flip a digit to make it pass.
• Treat two quantities on one line, a carton count that does not agree with a copy count, and a blurred or handwritten page as needs_human.
• Keep the book title in the script it was printed in. Do not translate it and then match the translation to the catalogue.
• If the OCR engine cannot read Chinese or Thai, stop. Do not ask a Latin model to imagine the page.
• Mark sample lines and keep them out of the billed quantity. If the page is unclear, leave the flag empty.
• Keep identity-card numbers and bank account numbers out of the ERP payload.
• Show the original page beside the fields. The approve button does nothing until a named person confirms they compared the lines to the scan.
• Call the ERP only with that approval, and only against a stub until the tests pass. The stub refuses a write that has no reviewer.
• Park credit notes and invoices. Version 1 does not turn them into sales orders.

The acceptance tests are in the file. A Malay order with two lines, a Chinese title left in Chinese, a missing ISBN, a quantity that might be cartons or copies, a confident model on a blurred scan, a bad check digit, a credit note, a duplicate PO, an approval with no reviewer, and a redacted identity number. If the ERP is called without an approval, the test fails.

That is the whole implementation. The agent does not get to skip the queue because a case study quoted 40%.

The instruction file

Here is the brief for your agent: the role, the sheets, the mailbox and the folder, the field schema, the validator, the review portal, the ERP stub, the privacy rules, the hard stop before any live write, and the tests that decide when a sandbox is allowed.

Replace every REPLACE line. Delete every SAMPLE row. Then let it run on old purchase orders before it sees this season’s pile.

Sources

Figures in this article come from Axrail’s Pelangi case study and from the AWS Partner Network post that quotes Pelangi’s executive director and describes SmartEye. They are not an independent audit. The 40% and the 25% are Axrail’s figures. AWS does not publish them.

• AWS Partner Network Blog, “Breaking Language Boundaries: Multilingual GenAI Solutions with Amazon Bedrock,” 17 September 2024, by Kelvin Kok and Cara Lee (Axrail) with Brendan Child and Vasileios Vonikakis (AWS). Pelangi’s adoption of SmartEye, the faster process with less human intervention, “achieving more with the same number of human resources,” and Sum Lih Kang’s quote: hundreds of thousands of physical documents a year, the Business Portal, unstructured and multi-language errors, Textract plus Bedrock, and reskilling 2–3 employees. Also the SmartEye architecture (S3, Lambda, Textract, Bedrock, DynamoDB, CSV) and the note on Latin-script Southeast Asian languages, Claude 2.1 and Claude 3. The post does not publish the 40% or the 25%. aws.amazon.com
• Axrail, “How we solved Pelangi's manual sales processing with AI.” The 40% less time per purchase order, the 25% lower manpower requirement over three years, the scan-to-email workflow, the six extracted fields, Claude structuring key-value pairs, admin review on the web portal before the order continues, SAP and Navision as examples in the general ERP diagram, the school-season peak, and the company background: founded in 1979, Malaysia with publishing offices in Thailand and Indonesia, curricula for Malaysia, Thailand, Indonesia, and Singapore, kindergarten to pre-university, more than 400 new publications a year in five languages. Vendor outcomes. axrail.ai