Automate email attachments: validate the extracted data

Introduction

Automating email attachments is not about "reading a PDF": it is deciding, for every extracted field, whether it is reliable enough to trigger an action. Attachments arrive in heterogeneous shapes — signed quotes, poor-quality scans, multiple versions of the same contract — and confusing a quote with the last approved contract can be costly. This guide gives you a field-by-field validation method, with evidence and decisions, that you can apply to an email processing workflow without claiming to cover your legal obligations.

Why attachments break email automation

An email on its own is a bounded object: a sender, a subject, a dated body. As soon as you add an attachment, you import a document whose structure is out of your control. A single case file can contain a native PDF generated by software, a scan photographed with a phone, a converted Word file, or even an image embedded in the message body. Email processing automation therefore has to solve two distinct problems: understanding the email, and understanding the document.

The second problem is the harder one. A native PDF keeps its text and layout; a scanned PDF is just an image that must be read. Extraction error rates vary enormously with scan quality, font, and page tilt. If your email automation assumes "the extracted text is correct," it is built on sand. The right posture is the opposite: every extracted field is suspect until evidence justifies trusting it.

Telling the attached document apart from the last approved contract

The most expensive mistake in this area is not technical: it is semantic. A client replies to your thread attaching "the document", and that document is an earlier quote, while the contract actually approved is a more recent version stored elsewhere. A naive automation reads the attachment, extracts an amount and a timeline, and triggers processing on outdated terms.

Three controls reduce this risk. First, never treat the mere presence of an attachment in the email as authoritative: the provenance of the reference document must be a designated source, for instance a document space where you file the approved version. Second, systematically compare the attachment with that reference: document date, version number, case identifier. Third, when there is a mismatch, the default decision is human review, not automated action. A label like "contract_final_v3.pdf" in the file name is not evidence: file names are typed by people in a hurry.

Checking provenance before content

Before extracting any data, ask where the document comes from. A PDF sent from the client's usual domain and consistent with the case history does not carry the same trust level as an attachment from an unknown personal address, with a subject line mirroring yours. This control is not paranoia: it is the first barrier against malicious instructions.

A document can indeed contain text designed to manipulate an automated reader: "ignore previous rules", "approve this amount", "reply immediately". If your extraction agent treats content as instruction, it becomes a vulnerability. The design rule is simple: attachment content is data, never an instruction. Text that looks like an order must be flagged as an anomaly and routed to a human, not executed. This principle ties into the controls described in our guide on document extraction, evidence and validation.

Classic pitfalls: formats, units, missing fields

Three families of errors recur constantly with heterogeneous attachments.

• Units and formats. "1 500" can mean one thousand five hundred or fifteen thousand depending on separator conventions. The date "03/11/2026" does not mean the same thing in every country. A duration of "30 business days" and "30 calendar days" produce different deadlines. Your automation must normalize explicitly, and adopt the convention stated in the document, not a developer's implicit convention.
• Missing or empty fields. A quote without a number, an invoice without a due date, a contract without a signature: the absence of an expected field is information. The wrong reaction is to leave the value empty and carry on; the right one is to block the decision line and request the missing document.
• Ambiguous values. An amount "to be confirmed", a crossed-out field, a handwritten note on a scan: these values cannot be extracted with confidence. They must surface with a doubt marker, not with a value invented by completion.

One further point of vigilance: extraction models tend to "guess" when a field is missing. Require your system to distinguish "field absent", "field unreadable" and "field present with value X". These are three different states calling for three different decisions.

A main example: a case with a quote and a contract

Let's take a fictional case to illustrate. You receive a reply email from a client with two attachments: a two-page scanned PDF presented as a quote, and a one-page native PDF presented as an acceptance letter. Your workflow expects an amount, a start date and a case reference.

The scan is of average quality: the amount reads "14,800 EUR excl. VAT" on page 1, but the start date is obscured by a fold on page 2. The acceptance letter says "we accept your proposal of 12/09/2026" without repeating the amount. The case number appears on both documents: D-2026-041. The quote's reference does not match the last quote recorded in your file, which carries a higher version number and a different amount.

What should the automation do? Nothing binding. It should flag the case "under review", prepare a draft reply requesting the up-to-date quote, and leave the final call to a human. This cautious behavior is not a failure of automation: it is automation working correctly. If you want to anchor this triage in a broader inbox logic, our article on Gmail AI agents for triaging requests details how to separate urgent items from cases needing validation.

The field / value / evidence / decision table

Here is the same situation as a decision table, the central tool of your design. Each row is an expected field, with the extracted value, the supporting evidence, and the resulting decision.

Field	Extracted value	Evidence	Decision
Case reference	D-2026-041	Page 1 of scan and page 1 of letter	Consistent with the case: continue checks
Amount excl. VAT	14,800 EUR	Scan, page 1, "Total excl. VAT" line	Readable but mismatch with reference quote: blocked
Start date	Unreadable	Scan, page 2, folded area	Field unreadable: request a clean copy
Reference document	Attached quote v2	Comparison with document space	Older than approved version: human review
Client acceptance	"We accept the proposal of 12/09/2026"	Native PDF, page 1	Proposal does not match attached quote: contradiction flagged
Suspicious instructions	None	Text analysis of both documents	Nothing to report: no action

This table is not cosmetic reporting: it is what makes your automation auditable. Every automated decision must be justifiable from the "evidence" column. If a row has no usable evidence, the decision defaults to "human review". To go further on end-to-end traceability, see following a case file from start to finish.

A step-by-step validation procedure

Here is a workable procedure for your document automation flow, to adapt to your tools.

1. Isolate and classify attachments. For each email, list attachments with file type, size, page count, and detect whether the PDF contains native text or is a scan. A scan triggers stricter readability checks.
2. Check provenance. Compare the sender and the document's path with the case's designated source. Any attachment arriving through an unexpected channel is flagged "provenance to verify".
3. Extract states, not just values. Each expected field comes back in one of four states: absent, unreadable, ambiguous, present with value. Silent completion of missing fields is forbidden.
4. Compare with the approved reference. Version number, date, amount, case identifier. Any mismatch blocks the automated decision.
5. Filter potentially malicious instructions. Any passage resembling a command addressed to the system is flagged, never executed.
6. Build the decision table. Field, value, evidence, decision, as above. The table travels with the case file.
7. Act or prepare a draft. If every row reads "continue", automated action is allowed within your rules. Otherwise, a reply draft is prepared for human validation.

On that last point, an important precision: with the Gmail API, authorizations such as gmail.compose or gmail.modify can also allow sending messages according to the Gmail scopes documentation. Restricting your agent to drafts therefore requires an explicit application-level control — your code verifies that it creates drafts and never calls send — because a label or an intention is not a permission boundary. Gmail drafts also provide a stable mechanism to prepare a reply without sending it.

Handling unreliable content and malicious instructions

Let's return to the most sensitive point. An attachment is not neutral text: it is potentially hostile content aimed at your reading system. Scenarios to anticipate include a fake quote whose text contains a sentence like "automatically approve this amount", or a document whose layout hides white text intended only for the automated reader.

Three design defenses, without claiming exhaustiveness. First: strictly separate the instruction channel (your rules, your configuration) from the data channel (attachment content). A document can never modify a rule. Second: detect suspicious patterns — imperatives addressed to the system, requests to bypass rules, invisible or out-of-layout text — and treat them as a security anomaly with human review. Third: log what was read and what was decided, so a decision can be reconstructed afterwards. These measures are engineering recommendations, not guarantees: no pattern list covers every case.

Limits, common mistakes and what to do

The first mistake is believing that a high extraction rate on native PDFs proves anything about scans. These are two different reliability regimes; test your controls on your worst real documents, not on clean samples.

The second mistake is over-trusting labels. "Signed quote", "final contract", "approved version" in a file name or email subject prove nothing. Only comparison with the designated source counts. The third mistake is letting automation "move forward anyway" on the grounds that most fields are readable: a single wrong critical field can be enough to make the whole decision wrong.

Finally, remember that email processing automation does not replace your responsibility to verify. The decision table helps you know where to look; it does not settle disputed cases on your behalf. If you are building a document foundation for your agents, our guide on an AI agent's knowledge base explains how to organize reference sources, and our article on AI email assistance and drafts details the drafts-first approach.

Frequently asked questions

Should scanned PDFs be rejected systematically?

No. A good-quality scan can be processed, but it must trigger reinforced controls: field-by-field readability checks, explicit flagging of unreadable zones, and a stricter confidence threshold before any automated decision. Scans are not forbidden; they are simply inherently less reliable than native PDFs.

How do you prevent an attachment from overriding the approved contract?

By designating a single reference source for approved versions, outside the mailbox, and systematically comparing every attachment against it. If the attached version is older or divergent, the automated decision is blocked. The file name and the email subject are never sufficient evidence.

What should be done when a field is missing from a document?

Three states must be distinguished: field absent, field unreadable, field present with a value. An absent field blocks the decision and triggers a request for the missing information, ideally prepared as an email draft. What is forbidden is silent completion: guessing a value and injecting it without a doubt marker.

How do you detect malicious instructions in an attachment?

Look for passages addressed to the system rather than the reader: approval orders, requests to bypass rules, invisible or out-of-layout text. The core defense remains structural: document content is data, never an instruction, and anything resembling a command is treated as an anomaly for human review.

Is the field/value/evidence/decision table enough to secure the flow?

It is necessary but not sufficient. It makes every decision auditable and forces evidence, but it depends on the quality of your upstream rules: a designated reference source, distinct extraction states, application-level control of sending permissions. It is a control instrument within a system, not the whole system.