How Documents and Emails Are Read

When a document is uploaded or an email arrives, the system reads it and fills in the fields it can recognize. This page covers what happens, which files work, how certain fields get filled, and what to do when it does not.

Manually created booking notes do not go through extraction. See Creating from a Blank Form.

How it works

1. The source arrives — a document is uploaded, or an email reaches the intake address.
2. A booking note is created immediately, with source Upload or Email and status Processing. It appears in the Requests list straight away, though it cannot be opened yet.
3. The system reads the source. For an upload, the document. For an email, the attachments and the body of the message.
4. Recognized values are mapped to fields. Values that could not be recognized are left empty.
5. The source is stored with the booking note as read-only reference material.
6. The note moves to Pending Review, or to Failed if there was not enough information to build one.

Emails: message and attachments

Both are read. Attachments are processed the way an upload is, and the body is read as well, so details appearing only in the message — a PO number typed into the email, a delivery instruction — are picked up and merged in.

Where the same detail appears in both the attachment and the body and the two disagree, the attached document is taken as correct.

An email with no attachment is processed from its body alone. A clearly written email containing the booking details produces a usable booking note.

What it does well, and what it does not

Extraction reads what is on the page. It is reliable for values that are clearly labeled and plainly stated, and less reliable where a value has to be inferred.

The following should always be checked:

Extraction is designed to save typing, not to remove review. Every extracted booking note goes to Pending Review for exactly that reason.

Empty is not an error. A field the system could not find is left empty rather than guessed at, and has to be completed by hand.

Checking against the original

The original document or email is shown beside the form, read-only, scrolling independently so the relevant part can stay in view while the fields are worked through. This is the fastest way to verify an extracted booking note, and the source stays attached permanently so anyone opening the note later can see what it was built from.

Which files work

Applies both to documents uploaded through Upload Document and to attachments sent to the email intake address.

Size limit: 20 MB per file.

If a file is too large, the usual cause is a scan at unnecessarily high resolution. Rescanning at a lower resolution, or exporting a compressed PDF, normally brings it well under the limit without affecting readability.

Getting good results

The format matters less than the quality of what is in it.

• Text-based files read best. A PDF generated from a system, a Word document or a spreadsheet contains actual text and gives the most reliable extraction.
• Clean scans read reasonably well. A straight, well-lit scan at normal resolution is fine. A skewed photograph of a crumpled page is not.
• Structured data reads well. Spreadsheets and CSV files with clear headers extract cleanly.
• Some things do not read at all. Handwriting, values that exist only inside a pasted image, and heavily stylized layouts where labels are visually separated from their values.

If a document reads badly on screen, it will read badly to the system.

One shipment per file. Each upload creates one booking note, and each email creates one booking note. A file containing several distinct bookings produces a single note with data drawn from across it, which is rarely the intended result.

How certain fields are filled

Most fields are populated only when the system finds a matching value. A few follow rules worth knowing, because they can produce a value that looks like it came from the source when it did not.

Cargo Ready Date

Taken directly from the source when a cargo ready date is found, and left empty when none is. The extracted date is then checked for plausibility: a date in the past, or more than six months ahead, raises a warning. See Errors and Warnings.

This date should always be checked. Date conventions are ambiguous, and a date read in the wrong one is still a valid date, so nothing on the form looks wrong.

Latest Shipping Date

Populated in order:

1. If the source gives a latest shipping date, that value is used.
2. If it does not, the Cargo Ready Date is copied into it.
3. If neither is available, the field is left empty.

The fallback exists so the booking note always carries a usable shipping date. It is not a value taken from the source.

A Latest Shipping Date identical to the Cargo Ready Date usually means the fallback was applied. Treat it as a field not yet filled in, and set the real date. This is the single most common thing to correct on an extracted booking note.

Shipper

Automatically populated and locked when the booking note was created by a Shipper through the portal. It records the originating Shipper organization and prevents the booking note being reassigned during review. See General Information.

Fields that already have a value

Priority Shipment, Payment Terms, Incoterms, Order Type and Dangerous Goods all carry a default on a new form.

If extraction finds no value for one of these, the default remains rather than the field being left empty. A field showing No or Collect may be an extracted value or may simply be what the form opened with, and the two are indistinguishable on screen.

All five should be confirmed against the source. Dangerous Goods matters most: if the source mentions hazardous cargo but the entry shows No, the classification was not recognized and has to be set by hand. See Dangerous Goods.

What to check before submitting

On any extracted booking note, the following should be checked before submitting:

• Latest Shipping Date — a real date, or the Cargo Ready Date copied in?
• Cargo Ready Date — does it match the source, in the right date convention?
• Ports — the right ports, checked by code rather than city name?
• Weights and volumes — do the totals in the Cargo header look right for the shipment?
• Payment Terms, Incoterms, Order Type — extracted, or just the defaults?
• Dangerous Goods — set correctly on every cargo entry?
• Empty fields — anything the system could not find that still needs completing?

If it fails

A booking note is marked Failed when the system could not build a usable booking note from the source it was given. The source arrived and was read, but there was not enough recognizable booking information in it.

Failed is a final state. A failed booking note cannot be edited and cannot be moved to another status.

Reprocessing is not available. There is no way to feed the source through extraction again. A new booking note has to be created — but the underlying problem must be fixed first, or the new one will fail the same way.

What to do

1. Open the failed booking note and check the reason. It states what went wrong and is the fastest way to decide what to do next.
2. Look at the source. Was it the right file? Was it readable? Did it actually contain booking details?
3. Fix and resubmit, or enter it manually.

Where a failure was a one-off, resubmitting the corrected source is quickest. Where the source will always be thin, manual entry is faster than trying to make extraction work.

Failed booking notes remain in the Requests list. Filter the Status column to Failed to see them, and save that as a view if failures need monitoring. They are records of what was attempted, not work in progress.