Extracting Data From a Fax Cover Sheet

A fax cover sheet looks like a form and it is tempting to extract it like one. It is more useful treated as two things: a routing slip that says where the rest of the transmission should go, and a checksum on whether all of it arrived.

What a cover sheet is actually for

The cover sheet is not part of the document behind it. It was written by the sender at send time, about the transmission, and its authority is limited accordingly: it tells you who claims to have sent what to whom, and nothing about the contents beyond a one-line subject. A field extracted from the cover sheet should never overwrite the same field read from the document itself. If the cover says “Invoice 4471” and the invoice says 4417, the invoice is right and the disagreement is a signal that the sender transposed digits — a useful thing to record, not a value to use.

The corollary is that the cover sheet earns its place in the pipeline by doing two jobs the document cannot do: telling you where to route the transmission before anything has read it, and telling you how many pages should be there.

The fields, and which are reliable

There is no standard cover sheet, but the field set is conventional enough to model once. Their reliability varies a great deal, and the schema should say so rather than treating them as peers.

• Recipient name, organisation and department. The routing fields, and usually the most reliable because getting them wrong means the fax does not arrive. Model them as separate fields; a single to string forces every consumer to re-parse it.
• Recipient fax number. Often a preprinted number on a departmental template, so it identifies the destination queue rather than the individual.
• Sender name, organisation and callback number. The callback number is the field a human will actually use, and it is frequently different from the sending fax number.
• Date. The date the sender typed or wrote, which may differ from the transmission date in the machine header. Keep both.
• Subject or “Re:” line. Free text, low reliability, but it frequently contains the reference number that makes the transmission matchable to an existing case.
• Page count. The important one; see below.
• The confidentiality notice. Boilerplate that is usually the longest text on the page. Detect and exclude it explicitly, or a summarisation step will faithfully summarise the legal notice instead of the message.

The page count is the useful field

Almost every cover sheet states a page count, and it is the only field on the sheet that can be checked against something independent. It lets you detect a truncated transmission before a human notices that a signature page is missing, which is the failure mode that costs the most downstream.

The catch is the phrasing. “Pages: 5”, “Number of pages including this cover: 5” and “Pages to follow: 5” mean two different totals, and the difference is exactly one. So do not extract a number. Extract a number and an inclusion flag, with a third state for when the sheet does not say:

{
  "page_count": { "value": 5, "confidence": 0.94 },
  "count_includes_cover": "unstated",     // "yes" | "no" | "unstated"
  "count_label_verbatim": "Pages to follow: 5"
}

Keeping the verbatim label is what lets a reviewer settle the case in two seconds instead of reopening the document, and it is the same argument as carrying the original header spelling in a merged-cell table. When the inclusion is unstated, treat both interpretations as acceptable rather than guessing: a transmission of six total pages satisfies “5” under either reading, and only a count that matches neither is a genuine discrepancy.

Three counts that disagree

You have three independent numbers, and each disagreement has a different diagnosis. This is the part that makes the cover sheet worth extracting at all.

• The count the cover sheet claims, written by a human before sending.
• The count in the machine header on each page, printed by the sending terminal as it transmitted — see fax header noise, where that line is stripped from the reading text but kept as metadata for exactly this purpose.
• The count of pages you actually hold, which is a property of the file.

When the header total and the file count agree but the cover claims more, the sender miscounted or removed a page after writing the cover; the transmission is complete as sent. When the cover and the header total agree but the file has fewer, pages were lost — in transmission, in the receiving gateway, or in your own ingestion, and the header numbers tell you which ones are missing by name. When the file has more pages than either claims, you are probably looking at two transmissions that were concatenated, which is the case the next section is about.

A missing page is a missing required field with a known cause, so route it as one rather than failing the document; the general handling is on handling a missing required field.

Handwriting and tick boxes

A large fraction of cover sheets are a printed template completed by hand, which changes the problem. The printed labels recognise perfectly and the values do not, so a naive extraction returns a confident field set full of empty or wrong values. Two adjustments help.

First, separate the template from the fill. Because the template is identical across every fax from that sender, the same cross-page repetition trick used for transmission furniture identifies the printed labels, and what remains is what the human wrote. Second, treat handwriting as a different confidence regime rather than the same one: a handwritten field deserves a much lower prior, and the general treatment is on handwriting recognition.

Tick boxes — Urgent, For review, Please comment, Please reply — are not text at all and should not be extracted as text. They are a small image classification: is this box marked. Model them as booleans with their own confidence, and note that a template where none is ticked is ordinary, so an all-false result is not evidence of failure.

Splitting the transmission

The reason to process the cover sheet first is that it lets you split the transmission before doing expensive work. A single received file often contains several logically distinct documents, and sometimes several distinct transmissions concatenated by the receiving gateway.

Use the cover sheet as a boundary marker: a page that classifies as a cover sheet starts a new logical transmission, and the machine header on each page — whose sending number and time change between transmissions — confirms the split. Then route each logical document by its type, so the invoice, the delivery note and the handwritten memo behind one cover go to three different schemas rather than one schema that has to be a union of all three. Where the split is ambiguous, that is a document-level review decision, and the fields it affects should carry that uncertainty through to per-field confidence rather than being resolved silently.