# Invoice data extraction: keep totals, balances and line items separate Source: https://www.digiparser.com/blog/invoice-data-extraction [See all posts](/blog) Last updated on October 1, 2026 # Invoice data extraction: keep totals, balances and line items separate Invoice processing Manufacturing Accounts payable [![Pankaj Patidar](https://avatars.githubusercontent.com/u/17493609?v=4) Pankaj Patidar @thepantales ](https://x.com/thepantales) ![Invoice data extraction: keep totals, balances and line items separate](https://cdnimg.co/676959fc-fff3-440b-8860-da6e53d455e3/16b9751f-4fb7-4a80-9f49-3ee614723ad3/invoice-data-extraction-office-sketch.jpg) Invoice data extraction turns a supplier PDF, scan or email attachment into named fields and line-item rows. Useful output keeps the **invoice total, amount already paid and remaining balance in separate fields**, then carries those values into a reviewed spreadsheet or configured accounting workflow. Reading the numbers is only the first step. Keeping their meaning is what makes the data usable. **Our recommendation: define the output before connecting the destination.** A parser that puts the right number in the wrong field can create more work than manual entry. This guide is for the team receiving supplier invoices: an office manager handling AP in a small manufacturer, an accounting team, or a finance systems owner. For orders received from customers, use the separate [customer PO processing guide](/blog/customer-purchase-order-processing). ## What invoice data should you extract? Start with the fields your receiving process needs. A useful extraction record has three parts: invoice identity, monetary values and line items. Keep a reference to the original document so a reviewer can check an uncertain value. Part of the record Fields to keep What to check Identity Supplier name, invoice number, invoice date, currency Keep invoice numbers as text; distinguish the supplier from the buyer Timing and reference Due date, payment terms, PO reference when present Do not confuse an invoice date with a due date Invoice amounts Subtotal, document discount, freight, tax, invoice total Preserve what each label means; avoid counting a charge twice Settlement amounts Amount paid, amount due, prior balance when shown Do not replace invoice total with the remaining balance Line items Description, item code, quantity, unit, unit price, line amount Keep each source row separate and check continuation pages Review context Source reference and unresolved fields Make missing or ambiguous values visible This separation is not an unusual custom requirement. [Amazon Textract's invoice field list](https://docs.aws.amazon.com/textract/latest/dg/invoices-receipts.html) defines total, amount due, amount paid, prior balance, discount and shipping as distinct fields. That is a useful model for your own field names, whether you use a cloud API or a configurable parser. OCR and invoice extraction also serve different purposes. Plain text can tell you that a page contains "880.00." An invoice-aware output should identify whether it is a line amount, a subtotal or the remaining balance. [Microsoft's invoice model documentation](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/invoice?view=doc-intel-4.0.0) describes extracting key fields and line items into structured JSON. ## Worked example: the invoice total is $1,080, but the balance is $880 Consider a fictional supplier invoice, `INV-0042`, in USD. It contains two rows: Description Quantity Unit price Line amount Replacement brackets 10 EA $60.00 $600.00 Seal kits 20 EA $20.00 $400.00 The document then shows these labelled amounts: Source label Printed amount Output field Line subtotal, before document discount $1,000.00 line\_subtotal Document discount $50.00 document\_discount Freight, not included in the lines $50.00 freight Tax $80.00 tax Invoice total $1,080.00 invoice\_total Payment received $200.00 amount\_paid Balance due $880.00 amount\_due The arithmetic for **this example** is: * Invoice total: $1,000 − $50 + $50 + $80 = **$1,080**. * Remaining balance: $1,080 − $200 = **$880**. The $80 tax is a printed value in this synthetic example, not a calculated tax rate or a tax rule. There is no prior balance, credit note or other adjustment. Real documents can use different subtotal conventions, so identify whether a discount or freight charge is already included before applying a formula. **Copying $880 into the invoice-total field understates this invoice by $200, even though the parser read $880 perfectly.** That is a field-mapping error, not a character-recognition error. The reverse mistake matters too: treating $1,080 as the remaining balance ignores the printed payment. Neither value alone authorizes a payment. AP must check the payment and balance against its accounting records. [Download the worked invoice as JSON](/research/invoice-data-extraction/worked-invoice.json). It is a proposed output structure with fictional data, not a captured DigiParser API response. The exact field names in your parser and destination can differ. ## Keep missing values different from zero A blank freight field does not mean free shipping. An invoice with no visible payment amount does not establish that nothing has been paid. A missing currency symbol does not establish USD or CAD. Use a clear policy in the output: * **Printed zero:** retain zero when the document explicitly says zero. * **Not present:** keep the field empty or null, according to the agreed output format. * **Ambiguous:** hold it for review rather than choosing a plausible value. * **Derived value:** label it as calculated; do not present it as text read from the invoice. Preserve the original label or a short source reference where your extraction and review setup supports it. That makes "total amount" versus "amount due" easier to resolve. If the invoice only shows one amount, the reviewer should establish its meaning rather than populate every monetary field with it. For dates such as `04/05/26`, confirm the supplier's date convention. For a document marked only with `$`, confirm currency from reliable supplier or transaction context. Keep any enrichment separate from the original extracted value. ## Five checks before the data leaves review These are checks to implement in your review process or receiving system. They are not a claim that every extraction product performs them automatically. **1\. Confirm the document type.** An invoice, supplier statement and credit note require different handling. A statement balance is not a new invoice total. Route mixed document batches deliberately. **2\. Check identity against the supplier record.** The printed supplier name is useful evidence, but it is not necessarily the internal supplier ID. Confirm the correct entity before creating an accounting record. Do not create a new supplier solely because its name has a spelling variation. **3\. Reconcile the amounts using the document's structure.** Compare line amounts, discounts, freight, tax and invoice total. Check whether charges appear inside the line table or outside it. Use the receiving system's approved rounding policy. A matching total is one check, not proof that the quantities, tax treatment or supplier are correct. **4\. Resolve duplicate candidates.** A supplier, invoice number and document type can help identify a candidate duplicate within the correct company record. A repeated attachment should not create a second bill. A corrected invoice needs an explicit decision, not silent rejection or automatic overwrite. **5\. Confirm the destination accepted the intended record.** An exported file or successful webhook delivery does not by itself prove that the right bill was created. Check the destination record, line count, currency and amounts. Preserve its reference with the source document. Microsoft's [invoice automation integration documentation](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/vendor-invoice-automation) treats invoice headers, lines and attachments as separate data entities. This is why the receiving system's requirements should shape the handoff. Extraction and accounting entry are connected stages with different responsibilities. ## Choose a useful output, not the most elaborate integration A spreadsheet can be the final destination for review or tracking. A configured accounting integration may be the right starting point for a team that already has a stable process. Neither requires the other as a mandatory first step. Destination Practical structure Acceptance check Excel or CSV One invoice summary row; separate line-item rows linked by a stable source ID Totals are not accidentally summed once per line JSON or an internal tool Invoice header with a line-items array Field names, null values, currency and amount types match the consumer Accounting or ERP workflow Explicit mapping to supported import or API fields Correct draft or bill, source attachment where supported, and destination reference For a line-level spreadsheet, be especially careful with repeated header totals. This example has two lines but only one $1,080 invoice. Summing a repeated invoice-total column across both lines would produce $2,160. Separate summary and detail tables, or group by the invoice's stable identifier before aggregating. The [downloadable JSON example](/research/invoice-data-extraction/worked-invoice.json) keeps the invoice amounts once at the header level and the two purchase rows inside `line_items`. It also records the example's assumptions and expected calculations. ## Run a pilot that reflects your team's actual work Choose documents because they exercise the workflow: multiple supplier layouts, multi-page lines, a printed discount, freight outside the lines, a part-paid invoice and an unclear field. Include ordinary invoices as well as difficult ones. Keep a reviewed expected result for each sample before comparing tools. Measure whether each document produces usable output, how long corrections take and whether the destination receives the correct record. Do not use a vendor's general accuracy percentage as a substitute for these checks. In an **11-50 employee manufacturer**, the person doing AP may also manage the office. Start with their real receiving process and confirm who can approve the trial and spend. At **51-200 employees**, check whether AP is centralized or still handled by a small office. At **201-500 employees**, a department can run the pilot while a systems owner verifies the handoff. Headcount does not establish purchasing authority. DigiParser lets you define invoice fields and line-item columns, add instructions for ambiguous fields, compare extracted results with the source, and export structured data. Your configured accounting process remains responsible for supplier records, matching, posting and payment. Test the fields and destination you intend to use rather than assuming this example is a default integration. **[Try DigiParser's invoice parser](/solutions/invoice-parser)** with a supplier invoice that has more than one labelled amount. Check the total, payment and balance separately, then verify the line items. For the broader operational rollout, see our [manufacturer supplier-invoice processing guide](/blog/vendor-invoice-processing). ## Common questions ### Is invoice data extraction the same as AP automation? No. Extraction turns invoice content into structured fields. AP automation can also include supplier checks, matching, approval, accounting entry and payment. Define which system owns each step before connecting them. ### Should I extract the invoice total or the amount due? Extract both when both are present. The invoice total describes the invoice; the amount due describes its stated remaining balance. A payment or adjustment can make them different. Confirm their accounting treatment in the receiving workflow. ### Can invoice line items go into Excel? Yes. Use separate rows for line items and link them to the invoice header. Keep header totals separate or use a grouping rule so repeated totals are not counted twice. ### Do different supplier layouts require different output fields? Not necessarily. Different documents can map to the same output fields. Test their labels and meaning, especially subtotal conventions, discounts and remaining balances. A consistent output format should preserve differences in the source, not erase them. * * * [See all posts](/blog) Automate recurring documents next: [supplier invoice parser](/solutions/invoice-parser), [customer purchase order parser](/solutions/purchase-order-parser), and [extract data from PDF](/solutions/extract-data-from-pdf) hub. ## Transform Your Document Processing Start automating your document workflows with DigiParser's AI-powered solution. [Start Free Trial](https://app.digiparser.com/auth/join)[Schedule Demo](/contact)