How to extract invoice data into Excel with AI and check every total

A tidy invoice spreadsheet is only the beginning

An assistant can turn an invoice PDF into a neat table and still misread the invoice number, omit delivery, confuse a subtotal with an amount due or repeat the same invoice twice. The presentation makes these errors easier to miss because each value now sits inside a familiar column. Start by defining what the spreadsheet is allowed to establish.

This workflow creates a reviewable extraction register. It does not approve an invoice, establish that goods arrived, validate a supplier's payment details or authorize a payment. Those actions require the organization's purchasing and accounting process. A calculated amount matching a printed amount is one useful check, not a complete approval.

The three downloadable invoices are fictional documents authored for this guide. They contain no real supplier, bank account or customer information. One includes a deliberate arithmetic discrepancy. The answer key is calculated from the sample documents; it is not a claim about the accuracy of a commercial AI tool or an observed extraction test.

Use those files for a first rehearsal. Keep your own tool's output unchanged, compare it with the answer key, and write down the differences. That record will tell you more about the proposed workflow than a general promise that AI can automate invoice processing.

Choose invoice-level or line-level rows

An invoice-level register has one row per document. It works well for invoice number, supplier, dates, currency, subtotal, discount, shipping, tax and amount due. A line-level table has one row per billed item or service. It is useful when you need quantities, unit prices, descriptions or purchase-order matching.

Do not mix those grains in one amount column. If an invoice has five line items and its full tax or total is repeated on each row, summing the column will multiply the amount. Keep invoice totals in an invoice table and line details in a separate table joined by a stable document identifier.

The practice template uses invoice-level rows. It includes the source filename and page, plus separate columns for stated amounts and calculated expectations. Invoice numbers remain text because 00041 and 41 may be distinct identifiers in the source. Dates use year-month-day when the source is unambiguous. Currency has its own column rather than relying on a symbol.

Choose the fields needed for your actual next step. Extracting every visible address and payment detail adds review work and can create unnecessary exposure. For the practice register, payment instructions are deliberately excluded. A missing field should be recorded as missing, not inferred from another invoice by the same fictional supplier.

Check the PDF before asking for a spreadsheet

Open every sample file. Look for the invoice number, the line items, the totals and the page count. A text-based PDF and a scanned picture of an invoice require different handling. A successful upload tells you that a file was accepted; it does not establish that the tool read every small number or table cell.

For scanned documents, use an approved OCR workflow where needed. Adobe documents creating searchable text from scanned PDFs and advises reviewing the recognized text for accuracy and completeness. OCR can make extraction possible, but it can also confuse a zero with a letter O, drop a decimal point or attach a number to the wrong column.

Check a few high-risk strings directly against the visual document: invoice number, date, currency code and final amount. If the PDF contains selectable text, copy a short section and compare it with the page. The text layer can be incomplete or out of reading order even when the document looks clean.

Record unreadable pages and request a better source rather than allowing a model to reconstruct them. A guessed tax amount that happens to make the invoice balance is still a guessed source value. Preserve the distinction between extracted text, uncertain recognition and a calculation made during review.

Sources: Adobe: recognize and review text in scanned PDFs

Give the assistant a precise extraction contract

Start with a small batch and a fixed schema. Tell the assistant to use only the supplied documents, preserve identifiers and return an issue for anything unreadable or not stated. Avoid a prompt that asks it to clean up or correct the invoice while extracting it. Correction can erase the evidence of a supplier-side discrepancy.

Use explicit null handling. A blank tax field can mean the invoice does not state tax, the tool could not read it or the field is genuinely inapplicable. Those situations should not collapse into a numeric zero. Add an issue column that explains why the amount is absent.

Ask for source references that a person can locate. Filename plus page and a nearby label is enough for a short practice document. A long invoice may also need section or line references. A source reference is useful only if it points to the exact amount, not merely the beginning of the PDF.

Specify the output format before running a batch. CSV is portable, but values containing commas, quotation marks or line breaks need correct quoting. A chat table is a preview, not proof that a usable spreadsheet file exists. Reopen the exported file and check that the column alignment survived.

Extract one invoice-level row per supplied PDF. Return SourceFile, SourcePage, InvoiceNumber, Supplier, InvoiceDate, DueDate, Currency, StatedSubtotal, StatedDiscount, StatedShipping, StatedTax, StatedAmountDue and Issue. Use only document evidence. Preserve invoice numbers as text. Do not infer missing dates, currency, zero tax or bank details. Leave an unreadable or unstated value empty and explain it in Issue. Do not correct printed amounts. Return a properly quoted CSV and a short coverage report listing every file and page read.

Work through the three fictional invoices

Invoice A, number 00041 from Cedar Office Supplies, has ten notebooks at USD 4 and five pens at USD 2. Its subtotal is USD 50, its stated tax is USD 5 and its amount due is USD 55. The document explicitly shows zero discount and zero shipping. These numbers describe an invented exercise, not a tax rule for any jurisdiction.

Invoice B, number 00042 from Harbor Print Studio, has a stated subtotal of USD 200, a discount of USD 20, delivery of USD 15 and tax of USD 18. Its amount due is USD 213. A tool that extracts only subtotal and tax might produce USD 218, while a tool that ignores delivery might produce USD 198. Both errors are visible once each adjustment has its own field.

Invoice C, number 00043 from Cedar Office Supplies, shows four desk mats at USD 25, no discount, no shipping and stated tax of USD 10. It prints an amount due of USD 109. Under the arithmetic rule printed on the sample, the expected amount is USD 110. The correct extraction preserves USD 109 and reports the USD 1 discrepancy separately.

Do not change the last invoice to USD 110 and call the extraction successful. The register needs to show what the document says and why it needs review. In an operational process, a reviewer would seek clarification or a corrected invoice instead of silently substituting the computed amount.

Calculate checks without rewriting the source

For these sample invoices, the stated exercise rule is subtotal minus discount plus shipping plus tax equals expected amount due. That rule is deliberately explicit. It is not a universal invoice formula: real documents can include tax-inclusive prices, withholding, deposits, credits, multiple tax rates or other adjustments.

Create ExpectedDue and Difference columns beside the extracted values. If the five amount fields are present, calculate the expectation and subtract it from the stated due. If a required field is missing, leave the check unresolved instead of substituting zero. A spreadsheet formula can be numerically valid while checking the wrong commercial rule.

Also compare line extensions with the stated subtotal when line-level detail is available. Multiply quantity by unit price using the document's own rounding convention, then account for stated line discounts or adjustments. Do not treat invoice-level and line-level rounding as interchangeable. Record a small discrepancy rather than forcing it into an undocumented rounding allowance.

Use exact currency units and a documented tolerance appropriate to the workflow. The practice amounts are expressed to two decimal places, so the USD 1 difference is unmistakable. Passing this check does not establish tax compliance, correct pricing or delivery. It establishes only that the stated amounts reconcile under the supplied rule.

Using the extracted sample fields, calculate ExpectedDue = StatedSubtotal - StatedDiscount + StatedShipping + StatedTax. Only calculate when every required amount is present and the currency is stated. Add Difference = StatedAmountDue - ExpectedDue. Keep all stated amounts unchanged. Flag nonzero differences and missing inputs for review. Explain that this arithmetic rule belongs to the supplied practice documents and does not establish tax treatment or payment approval.

Look for duplicates without deleting evidence

A second copy of a PDF can produce a second row even though there is only one invoice. File names are not reliable business identifiers: invoice-final.pdf and invoice-final-copy.pdf may contain the same invoice. Conversely, two suppliers can independently use the same invoice number.

Use a duplicate-candidate rule that includes supplier identity, invoice number and relevant context such as currency and amount. Preserve the original source references for every candidate. A matching number is a reason to investigate, not permission to discard a row or merge two supplier records.

Revisions need particular care. A corrected invoice may retain the original number while changing its date or amount. Record which document supersedes which only when the source supports that relationship. Keep a status such as awaiting supplier clarification rather than choosing the latest-looking filename automatically.

For the practice exercise, make a copy of invoice A under a different filename and run a second batch. A useful output should identify a possible duplicate without claiming a second liability. Remove your temporary copy after the rehearsal, and keep the original three-document answer key distinct from this optional four-file test.

Reopen the exported spreadsheet and inspect the values

After downloading the assistant's output, open it with deliberate import settings. Invoice numbers must remain exact strings, dates must not switch locale, and amounts must stay numeric. A currency symbol pasted into every amount cell can make calculations awkward; use a separate currency column and number formatting in the spreadsheet application.

Check the number of source files against the number of invoice-level records and the list of exceptions. Three supplied documents should not quietly become two rows because one was unreadable. Nor should one two-page invoice become two invoices unless the task deliberately uses page-level records.

Inspect a row from each distinct layout and every row with an issue. In the sample, inspect all three. Compare the CSV field order with the template and ensure commas in supplier names or descriptions have not shifted later fields. Preserve the source filename when sorting so a reviewer can still find the document.

If formulas have been added, inspect representative formulas rather than relying on displayed totals. A hardcoded answer and a live calculation can display the same number today but behave differently when a corrected invoice arrives. Keep source values, calculated checks and human review decisions visibly separate.

Related guide: Compare two spreadsheet versions using stable keys

Turn extraction issues into a useful review queue

An issue column should say what the next reviewer needs to do. Amount unclear on page 2 is actionable. Low confidence is less useful unless it is connected to a particular field and evidence. Avoid treating an assistant's confidence percentage as a calibrated measure of accounting accuracy.

For invoice C, the next action is to resolve the printed USD 109 against the USD 110 arithmetic expectation. The reviewer should not infer whether the supplier intended a discount, made a typo or calculated tax incorrectly. The exercise supplies no evidence to choose among those explanations.

Add a separate human decision field when the register becomes part of an operational process. It can record unresolved, corrected source received, excluded as duplicate or reviewed for the defined extraction task. Do not label a document approved simply because its fields have been extracted and its arithmetic reconciles.

Keep the source PDFs available to the authorized reviewer and retain the method used to create the register. If a tool or prompt changes, rerun a small known sample before using it on the next batch. A prior good result on three simple documents does not establish performance on photographed receipts, foreign-currency invoices or long statements.

Decide whether a general assistant is enough

For occasional documents, a general assistant plus a careful review may be sufficient. For recurring high-volume processing, evaluate a dedicated extraction or document-processing service against your own document layouts, access requirements and exception workflow. The useful question is how errors are detected and resolved, not whether the product advertises automation.

Build a representative evaluation set using authorized examples. Include multi-page invoices, credits, different currencies, missing fields, unusual separators and poor scans. Keep a human-checked reference set and compare field-level results. Do not describe a handful of favorable examples as a measured accuracy rate for all invoices.

Ask how the service handles a failed document. It should preserve the failure and source reference, allow correction, and prevent an unresolved row from passing silently into the next system. Also ask how revisions and repeated imports are recognized. A correct one-off extraction can still create duplicate records in a recurring process.

Start the live workflow with a review boundary that the team can actually maintain. Preserve organization-approved handling of supplier and customer information, and avoid exposing payment details merely to complete a tutorial. The practice pack is intentionally fictional so the learning step does not depend on uploading real operational documents.

Questions to answer before the next batch

Can AI extract an invoice from a photo? Some tools can process images, but readability, supported input formats and account capabilities vary. Use an approved OCR or image-reading path, inspect the result and retain an unresolved state for unclear fields. A photo should not be called verified simply because the tool returned a table.

Should a blank amount be zero? Only when the source or a documented business rule establishes zero. The practice PDFs state their zero adjustments explicitly. The blank template deliberately contains no implied amounts, so a partially completed row cannot be mistaken for a balanced invoice.

Can the totals be combined across currencies? Keep separate totals per currency unless a defined conversion process supplies rates, dates and treatment. A USD amount and an EUR amount cannot be added into a meaningful single invoice total by dropping their currency codes.

The first useful deliverable is a complete register with traceable fields and visible exceptions. Once that works on the sample, rehearse the review process with the person who will own it. Extraction becomes valuable when someone can explain and resolve the uncertain rows, not when every cell has been filled.