The revised SI arrives as a scan, and the draft B/L is due back tomorrow
A customer sends revised shipping instructions ten minutes before you planned to return the draft bill of lading to the carrier. The PDF is a scan, slightly crooked, with three fields changed and no summary of what moved. Somebody has to read every line of the new version against the old one, then check the draft B/L reflects exactly what was authorised, and nothing else.
This is the moment document work goes wrong. The operator is in a hurry, the changes look small, and a single unchecked field, a notify party address, a package count, a freight-payable term, becomes a correction request after the B/L is issued, when a correction after issue means a fresh amendment round with the carrier.
What extraction tools actually do for this file
Document extraction services read the text and structure out of document files so software can compare field values instead of a person retyping them. Amazon Textract’s AnalyzeDocument operation takes a document file, supplied as image bytes or as an object in S3 storage, and returns the analysed text as structured JSON. Google Cloud’s Document AI organises the same job around processors, including OCR, a form parser and custom extractors that can be trained for a specific document layout.
None of that is freight knowledge. An extractor does not know which SI revision is authorised, which fields the customer actually approved, or whether the draft B/L the carrier returned matches the request. It turns pixels into values. Everything after that, deciding what counts as a change and whether it is acceptable, is workflow design, and it is where a forwarder’s process either holds or leaks.
One caution from the vendor record: Google deprecated Document AI’s human-in-the-loop feature in January 2024, so a review step built on that product needs a different home for the human decision. Amazon’s Augmented AI keeps the pattern explicit, with a StartHumanLoop call that starts a human review when an activation condition is met, tied to a flow definition and the review input. The pattern is worth copying whatever you build on: extraction proposes, a named person approves, and the approval is recorded against a specific document revision.
A practical design: extract, compare, approve, verify
For example, a customer revises SI version 2 for one 40HC on a Felixstowe sailing. The changes are a corrected notify party address, a package count moving from 120 to 118 cartons, and a freight-payable term confirmed as prepaid. The operator runs both SI versions and the draft B/L through extraction, and the comparison shows exactly three differences between the SI revisions, plus one surprise: the draft B/L still shows 120 cartons.
That mismatch is where the design earns its place. Without the comparison, the operator can return the draft marked as good and the error surfaces after issue. With it, the correction goes back to the carrier before anything is final, attached to the authorised revision and the three approved field changes.
Our playbook for correcting shipping instructions or a draft B/L sets out the underlying discipline this automation should serve: an approval belongs to a specific document revision and a specific set of field changes, and the returned revision gets checked against both. Build the tooling around that rule, not around the extraction demo. The same verification habit applies to booking confirmations, as described in checking the amended confirmation before telling the customer: never pass a document onward until the returned version has been compared with what was approved.
Where to keep the human, deliberately
Three decisions should stay with people. First, whether the revised instructions are authorised at all, which is a commercial judgement no extractor can make. Second, whether an ambiguous read, a smudged character in a container number, a handwritten amendment in a margin, is resolved by going back to the customer rather than guessing. Third, the final sign-off on the draft B/L returned by the carrier, because that signature commits the company.
Everything else is legitimate automation territory: pulling the text out of scans, aligning two revisions field by field, flagging differences, assembling the correction request, and keeping the audit trail of who approved what and when. Score any proposed tool against that split. If a vendor demo shows extraction accuracy but has no answer for where the approval is recorded and how the returned revision is re-checked, it has solved the easy half of the file.
Start with one document pair
Pick one lane or one customer whose SI revisions cause the most rework, and run the extract-and-compare routine alongside the current manual check for a month. Count what the comparison catches that the manual read missed, and what it flags wrongly. That record is also the specification for a deeper workflow: our work on shipping instruction and draft B/L corrections starts from exactly this comparison, with approval and returned-revision verification built in.
Talk to us about one of your revised SI files and the draft B/L that followed it. Let’s talk: we will review the pair with you, trace where the checking time goes, and identify which parts of the comparison a supervised workflow could take over while your team keeps every approval.