Tender documents are not text, and extraction has to know it
Tender packs arrive as PDFs, spreadsheets and scans whose meaning lives in tables, cell colours, nested requirements and CV layouts that plain-text parsing flattens. Klarum extracts with that structure preserved, which matters to anyone who has to read a pack under deadline, and it still fails on the worst scans.
Limitations come first
Extraction is the least glamorous capability we ship and the one every other capability depends on. It is also imperfect. A poor scan, a skewed photograph of a page or a table drawn as loose lines of text will lose information, and we do not claim otherwise. Where a document defeats the extractor, a bid manager still needs to read it. We have not published an accuracy figure, and this piece does not offer one.
What a tender pack really is
A tender pack, whether found on a public portal such as Tenders Electronic Daily[1], is rarely a clean document. It is a bundle: a terms-of-reference PDF, a pricing spreadsheet, a scanned annex with a stamp on it, and a stack of consultant CVs in whatever layout each person preferred. The meaning of each file sits in its structure rather than in its words.
Run that bundle through a plain-text parser and the structure is the first thing to go. A table becomes a run of words with no columns. A requirement that sits beneath a heading, beneath a sub-heading, becomes a sentence with no parent. A spreadsheet cell shaded to mean mandatory loses the shading and with it the meaning. A CV loses the boundary between one role and the next, so a ten-year career reads as one long paragraph.
What extraction preserves
| Document feature | Plain-text result | What we keep |
|---|---|---|
| Tables | A stream of words | Rows, columns and headers |
| Cell colours | Nothing | The colour, so shaded cells keep their meaning |
| Requirement hierarchy | Flat sentences | Parent and child relationships between requirements |
| CV structure | One block of prose | Roles, dates, qualifications and projects as separate fields |
| Scans | Blank or garbled | Recognised text, with errors where the scan is poor |
The point is that downstream work gets a structured record rather than a wall of text. Requirement checklists can be suggested from the tender. Team members can be matched against the capabilities a tender asks for. Both depend on knowing which line is a requirement and which person did what.
Who this affects
Bid managers feel it first. Reading a pack carefully is the work that always runs late, and a requirement missed in an annex is the kind of error that costs a bid. Technical leads feel it next, because a CV that has been flattened cannot be matched against a post. Finance staff feel it on spreadsheets, where a shaded cell is a rule rather than decoration.
It also affects inbound work. Attachments sent to a firm through its own portal are parsed the same way on arrival, so an applicant document becomes structured project data without anyone retyping it.
What we would change first
We would show the source page beside each extracted item, so a reader can check any line against the original in one glance. Extraction you cannot audit is extraction you have to redo by hand, and that defeats the purpose.
The trade: structure kept, trust still earned
Keeping structure turns a pack from something to be read into something that can be worked with. It does not remove the need to check. For clean digital files we expect the result to be dependable, and for poor scans we expect to be wrong sometimes. Treat extraction as a fast first pass over every document, with the human reading reserved for the places where it matters.
References
- [1]Tenders Electronic Daily. Publications Office of the European Union. The official journal of EU public procurement, and the largest single source in the corpus.