Contracts, invoices and PDFs into structured fields that hold up. Below are 7 copy-ready prompts. Fill in the [BRACKETS], copy, and paste into ChatGPT, Claude, Gemini or any capable assistant.
Extraction is the most production-ready use in this pillar, because you can define the output schema, validate it, and catch failures automatically.
The 7 prompts
Extract structured data from a document
Pull specific fields out of a contract, invoice or report.
Extract data from this document. DOCUMENT: """ [PASTE] """ DOCUMENT TYPE: [CONTRACT / INVOICE / REPORT / FORM / STATEMENT] WHAT I NEED: [THE FIELDS] OUTPUT FORMAT: [table / CSV / JSON] WHAT THIS FEEDS INTO: [WHERE THE DATA GOES] Extraction rules: - Extract only what is stated. Never infer a value and present it as extracted. - Preserve exact wording, numbers and units. Do not convert, round or normalise. - Where a field appears more than once with different values, report both and flag the conflict. - Where a value is ambiguous, extract it with a note explaining the ambiguity. - Where a field is genuinely absent, write NOT STATED. Do not leave it blank, which is indistinguishable from an oversight. Output: 1. THE EXTRACTED DATA in my requested format. 2. THE SOURCE QUOTE for each field - the phrase it came from, so I can verify without rereading the document. For anything financial, legal or date-related, this is mandatory. 3. EXTRACTION NOTES - anything that was not a clean extraction: ambiguous, conditional, conflicting, or stated in an unusual place. 4. THE CONDITIONAL VALUES - fields whose value depends on a condition stated elsewhere in the document. These are the most commonly mis-extracted, because the headline figure is not the operative one. Flag every instance. 5. NOT FOUND - fields I asked for that the document does not contain, and whether the document indicates they exist elsewhere. 6. CONFIDENCE - which fields were reliably extractable and which required judgement. 7. WHAT ELSE IS IN HERE that I did not ask for but that bears on the fields I did - a deadline attached to a figure, an exception to a term, a cross-reference to another document. Accuracy over completeness. A NOT STATED is better than a plausible guess, particularly for anything that will be acted on.
What you get: Structured extraction with source quotes, conditional values flagged, conflicts reported and absent fields marked explicitly.
Tip: Point 4 is where document extraction usually goes wrong. The headline number in a contract is frequently overridden by a condition three clauses later.
Find what you need in a long document
Locate the relevant part of something you do not want to read fully.
Help me find what I need in this document. DOCUMENT: """ [PASTE] """ WHAT I AM LOOKING FOR: [YOUR QUESTION] WHY: [WHAT YOU WILL DO WITH THE ANSWER] DOCUMENT TYPE: [WHAT IT IS] Produce: 1. THE DIRECT ANSWER - if the document answers my question, the answer with the exact passage quoted and its location. Lead with this. 2. IF IT DOES NOT ANSWER IT DIRECTLY - the closest relevant passages, quoted, and what can and cannot be inferred from them. Be explicit about the difference between what the document says and what you are inferring. 3. THE QUALIFICATIONS - anything elsewhere in the document that modifies, conditions or contradicts the answer. This is the critical section: the answer to a question is frequently in one place and its exception is in another, and reading only the first is how people get this wrong. 4. THE RELATED PROVISIONS - other parts bearing on my question that I did not know to ask about. 5. THE DEFINITIONS - any term in the relevant passages defined elsewhere in the document with a meaning different from ordinary usage. Documents frequently define common words in uncommon ways, and missing that reverses the meaning. 6. THE CROSS-REFERENCES - anywhere the relevant sections point to other documents, schedules or appendices I would also need. 7. WHAT THE DOCUMENT IS SILENT ON - if my question is not addressed, say so plainly rather than constructing an answer from adjacent material. Silence in a document is often deliberate and meaningful. 8. THE PRACTICAL ANSWER - given what I said I will do with this, what it means in practice, with the caveat that this is a reading of the text and not advice. Quote everything. Do not paraphrase a provision I will rely on.
What you get: A direct quoted answer plus the qualifications elsewhere, defined terms, cross-references and an explicit note where the document is silent.
Tip: Point 3 is the one that matters. The clause you found says one thing; the clause you did not find says 'except where'.
Compare two versions of a document
Find what changed between drafts.
Compare these two versions. VERSION A (earlier): """ [PASTE] """ VERSION B (later): """ [PASTE] """ DOCUMENT TYPE: [CONTRACT / POLICY / SPECIFICATION / REPORT] MY POSITION: [WHOSE SIDE YOU ARE ON, if relevant] WHAT I CARE ABOUT: [YOUR PRIORITIES] Produce: 1. THE SUBSTANTIVE CHANGES - a table: Section | Version A | Version B | What changed | Effect | Significance (material / minor / cosmetic) Every change that alters meaning, obligation, timing, amount, or risk. 2. THE DELETIONS - what is in A and absent from B. These are the easiest changes to miss and often the most significant, because there is nothing new to read. 3. THE ADDITIONS - what is new in B. 4. THE SUBTLE CHANGES - the ones that look editorial and are not: - 'shall' to 'may', or 'must' to 'should' - 'and' to 'or', which changes conditions fundamentally - 'including' to 'including but not limited to', or the reverse - A deadline expressed differently: 'within 30 days' versus 'within 30 business days' - A qualifier added or removed: 'reasonable', 'material', 'promptly' - Singular to plural - A defined term replaced with an ordinary word, or vice versa Flag every one. These carry the largest effect per character changed. 5. THE DEFINITION CHANGES - any change to a defined term propagates everywhere that term is used. List each and the sections affected. 6. EFFECT ON MY POSITION - if I told you my side, which changes help me, which hurt me, and which are neutral. 7. THE CHANGES TO QUERY - what to ask about, phrased neutrally. 8. WHAT DID NOT CHANGE that I might have expected to, given the context. Quote both versions for every change. Do not summarise a difference I will act on.
What you get: A significance-rated change table with deletions separated out, subtle wording changes flagged, and the effect on your position.
Tip: Point 4 is where negotiations are won and lost quietly. Changing 'and' to 'or' in a conditions clause can reverse an obligation, and it looks like a typo.
Process a batch of similar documents consistently
Extract the same fields from many files reliably.
Help me process a batch of documents. SAMPLE DOCUMENT: """ [PASTE ONE REPRESENTATIVE EXAMPLE] """ A SECOND, SLIGHTLY DIFFERENT ONE: """ [PASTE - IDEALLY ONE THAT VARIES IN FORMAT] """ DOCUMENT TYPE: [WHAT THEY ARE] HOW MANY: [BATCH SIZE] WHAT I NEED FROM EACH: [THE FIELDS] WHERE THE DATA GOES: [DESTINATION] HOW THEY VARY: [WHAT DIFFERS BETWEEN DOCUMENTS] Produce: 1. THE FIELD SPECIFICATION - for each field: what it is, its expected format, whether it is always present, where it typically appears in the document, and the variations you can see between my two samples. 2. THE EXTRACTION RULES - precise enough to apply consistently across the batch. For each field: how to identify it, what to do when it appears in a different place or format, and what to do when it is absent. 3. THE AMBIGUITY RULES - decided in advance, because inconsistent handling across a batch is worse than a consistent wrong choice. For each likely ambiguity: the rule to apply. Examples: which date when several appear, which total when there is a subtotal and a total, how to handle a field split across lines. 4. THE VALIDATION RULES - checks to run on each extracted record: required fields present, dates within a plausible range, numbers positive where they should be, totals reconciling with components, and formats consistent. 5. THE EXCEPTION HANDLING - what to do with a document that does not fit the pattern. Do not force it; flag it for manual review. Say what proportion of exceptions is normal and when a high rate means the rules are wrong. 6. THE PROMPT TO USE per document - a reusable prompt with the rules embedded, so every document is processed identically. 7. THE OUTPUT SCHEMA - the exact structure, with a field for the source document and a field for extraction flags. 8. THE QUALITY CHECK - how to verify the batch: sample a subset and check against the source manually. Say what sample size is worth checking and which records to prioritise (exceptions, extremes, and a random sample). 9. WHAT NOT TO AUTOMATE - fields where the judgement required makes automated extraction unreliable. Be honest about these rather than producing plausible values.
What you get: A field specification with variations, pre-decided ambiguity rules, validation checks, a reusable per-document prompt and a quality sampling plan.
Tip: Point 3 is what makes batch extraction usable. An inconsistently applied rule produces data you cannot trust anywhere, which is worse than a consistently applied imperfect one.
Summarise a technical or legal document for a non-specialist
Explain a dense document to someone who needs to act on it.
Explain this document. DOCUMENT: """ [PASTE] """ WHAT IT IS: [TYPE] WHO NEEDS TO UNDERSTAND IT: [ROLE AND EXPERTISE] WHAT THEY NEED TO DO: [THE DECISION OR ACTION] WHAT THEY ARE WORRIED ABOUT: [THEIR CONCERNS] Produce: 1. WHAT THIS DOCUMENT DOES - two sentences, plain words. 2. THE PARTS THAT AFFECT YOU - given the reader's stated role and action, only the provisions that matter to them. A complete summary is less useful than a relevant one. Quote each and explain it plainly. 3. WHAT YOU MUST DO - obligations, with deadlines. As a list, with the section reference for each. 4. WHAT YOU MUST NOT DO - prohibitions and restrictions. 5. WHAT YOU CAN DO - rights and options that might not be obvious. 6. THE DEADLINES AND DATES - every time-bound element, as a table, with what triggers each clock. Missed deadlines are the most common practical failure, and a deadline that runs from an event rather than a fixed date is easy to miss. 7. THE CONDITIONS - things that only apply in certain circumstances, written as IF/THEN so the reader can check whether they apply. 8. THE DEFINED TERMS that mean something different from ordinary usage. Give each one's document meaning next to the ordinary meaning. 9. THEIR SPECIFIC CONCERNS - each thing I said they are worried about, addressed with the relevant provision quoted. If the document does not address a concern, say so. 10. WHAT NEEDS PROFESSIONAL ADVICE - the parts where the consequence of misunderstanding is serious enough that a lawyer, accountant or other specialist should review it. Be specific about which provisions, rather than a blanket disclaimer. Rules: - Quote the document for anything that will be acted on. Do not paraphrase an obligation. - Do not simplify to the point of changing the meaning. Where something is genuinely complex, say so and explain it rather than flattening it. - This is a reading aid, not advice. State that plainly at the end.
What you get: A role-relevant explanation with quoted obligations, a deadline table with triggers, conditions as IF/THEN and specific points needing professional review.
Tip: Point 6's trigger column is the practical one. A deadline running from 'the date of notification' is far easier to miss than a fixed date, and it is the one that catches people.
Build a timeline from documents
Reconstruct a sequence of events from scattered records.
Build a timeline from these documents. DOCUMENTS: """ [PASTE EACH, LABELLED WITH ITS TYPE AND DATE IF KNOWN] """ WHAT I AM TRYING TO ESTABLISH: [YOUR QUESTION] CONTEXT: [WHAT THIS IS ABOUT] Produce: 1. THE TIMELINE - chronological, each entry with: date, time if available, what happened, the source document, and a direct quote. Where a date is inferred rather than stated, mark it [INFERRED] and give the basis. 2. THE THREE DIFFERENT DATES - distinguish rigorously, because conflating them is the main source of error in reconstructed timelines: - When the event occurred - When it was recorded or documented - When someone was informed of it A document dated the 14th describing something that happened on the 9th is two entries, not one. 3. THE GAPS - periods with no documentation. State them explicitly as gaps rather than allowing the timeline to imply continuity. Say what would fill each. 4. THE CONFLICTS - where documents disagree about what happened or when. Quote both, and do not resolve them silently. Note which document would normally be more reliable for this kind of fact and why. 5. THE AMBIGUOUS DATES - relative dates ('last week', 'shortly after'), ambiguous formats where day and month could be swapped, missing years, and time zone issues. Flag each rather than assuming. 6. THE SEQUENCE QUESTIONS - where the order of two events matters for my question but cannot be established from the documents. These are often the crux. 7. WHAT THE TIMELINE SHOWS regarding my question - and what it does not. 8. THE MISSING DOCUMENTS - what would exist if these events happened as documented, and is not here. Absence can be significant. 9. THE CAVEAT - this timeline reflects what these documents say, which is not necessarily what happened. Documents are created by people with perspectives and interests. Note any document whose author had a stake in how events are recorded. Quote everything. A timeline entry without a source is an assertion.
What you get: A sourced chronological timeline distinguishing occurrence from recording from notification, with gaps, conflicts and ambiguous dates flagged.
Tip: Point 2 is the discipline that makes reconstructed timelines reliable. The date on a document is almost never the date of the event it describes.
Convert a document into a structured format
Turn prose into a usable data structure.
Convert this document into a structured format. DOCUMENT: """ [PASTE] """ TARGET FORMAT: [JSON / YAML / CSV / database table / markdown table] WHAT IT WILL BE USED FOR: [PURPOSE] SCHEMA I ALREADY HAVE: [PASTE, or 'design one'] Produce: 1. THE STRUCTURE ANALYSIS - what natural structure exists in this document: sections, repeated patterns, hierarchies, lists, key-value pairs, and tabular content. Identify what is genuinely structured and what is prose that only appears structured. 2. THE SCHEMA - if designing one: field names, types, whether each is required, nesting where the source is hierarchical, and how repeated elements are represented. Explain each decision. 3. THE HARD PARTS - content that does not map cleanly: - Prose that contains several facts in one sentence - Conditional or qualified statements, where flattening loses the condition - Cross-references between sections - Content whose meaning depends on its position in the document - Footnotes and exceptions attached to a value For each, the options and what each loses. 4. THE LOSS ASSESSMENT - structuring prose always discards something: nuance, qualification, ordering, and context. State explicitly what this conversion loses and whether it matters for my stated purpose. This is the section people skip and later regret. 5. THE OUTPUT - the converted document. 6. THE UNCONVERTED - anything that could not be structured without distorting it, kept as text in a notes field rather than forced into a schema. 7. THE VALIDATION - how to check the conversion is faithful: counts of records against the source, spot checks on specific values, and a check that no required field is systematically empty. 8. THE ROUND-TRIP QUESTION - could someone reconstruct the meaning of the original from this structure? If not, say what needs to be preserved alongside it. Keep a reference to the source document in every record. Do not force content into the schema. Flagging something as unstructurable is a legitimate result.
What you get: A schema derived from the document's real structure, hard cases handled explicitly, a loss assessment and a validation plan.
Tip: Point 4 is worth reading before you commit. Structuring a document with conditional clauses into flat fields silently discards the conditions, and nobody notices until it matters.
Where AI actually helps here
- Pulling defined fields from contracts, invoices and forms into JSON
- Normalising dates, currencies and formats across a messy set
- Flagging documents that do not match the expected shape
Where it falls down
- Filling a field it cannot find. Without explicit instruction it guesses a plausible value
- Complex table layouts, merged cells and multi-column PDFs
- Scanned documents, where the OCR errors arrive before the model does
The mistake almost everyone makes: Not defining the empty case
Every extraction prompt needs: if a field is not present in the document, return null. Do not infer it, and do not use a value from elsewhere in the document. Without it, a missing invoice date becomes the date it found somewhere else, and nothing in the output marks it as a guess.
Free tool: Prompt Templater
Runs in your browser. No sign-up, nothing uploaded.
Questions people ask
How accurate is AI at extracting data from PDFs?
Good on clean, structured, text-based documents; unreliable on scans and complex tables. Build validation in — required fields, format checks, ranges — and review anything that fails rather than sampling randomly.
How do I get consistent JSON output?
Give the exact schema, provide one filled example, require null for missing values, and use the model’s structured-output or JSON mode if it has one. Then validate every response against the schema and retry failures.