How ADE extracts structured data from invoices, purchase orders, delivery notes, and remittance advice across thousands of vendor formats without templates.
Accounts payable teams process documents from hundreds or thousands of vendors, each using a different invoice format, different field labels, and different table structures. The same semantic information (vendor name, invoice number, line items, due date, total) appears in a different position and under a different label in every vendor's document. Template-based systems require a template per vendor; ADE handles the full vendor base from a single extraction schema.
Why AP Documents Break Template Systems
Invoice variability is structural, not incidental. A vendor in one industry may issue a clean three-column PDF with a summary table; a vendor in another may issue a scanned document with handwritten line items and a signature stamp. Currency and tax conventions differ across regions: VAT, GST, and service charges all appear in different formats and positions. Labels are inconsistent: "Invoice No.," "Invoice #," "Inv ID," and "Bill ID" all refer to the same field. The word "Total" can refer to a line total, a subtotal, or the final payable amount depending on context and placement.
Template-based systems encode field positions as coordinates. When a vendor changes its invoice layout, or a new vendor is onboarded, the template breaks and extraction produces null fields or wrong values. The maintenance burden grows linearly with vendor count.
How ADE Processes AP Documents
ADE's Document Pre-Trained Transformer treats each document as a visual system, identifying field-value relationships from layout and context rather than fixed coordinates. It understands that "Invoice No." and "Invoice #" refer to the same field by reading contextual proximity and document structure, not by pattern-matching against a stored rule. The Parse API converts any AP document into layout-aware Markdown and hierarchical JSON with bounding-box grounding on every element, preserving line-item tables regardless of the number of rows or whether gridlines are present.
LandingAI trains the DPT models on curated domain-specific datasets that include the format variability present in real financial workflows, as described in the invoice parsing technical post. This focused training allows the model to recognise how fields relate to each other across formats, how line-item structures behave, and how totals, taxes, and currencies connect within different layouts.
The Four AP Document Types and Their Schemas
AP automation typically covers four document types, each handled by a dedicated extraction schema:
Invoices. The core AP document. Key fields: vendor name and tax ID, invoice number, invoice date, due date, PO reference, billing address, line items (description, quantity, unit price, line total), subtotal, tax type and amount, total payable, currency, and payment terms. The line items schema uses a typed array to handle any number of rows without encoding the expected row count.
Purchase orders. The counterpart document used for three-way matching. Key fields: PO number, issue date, buyer entity, vendor entity, delivery address, line items (item code, description, quantity ordered, unit price, line total), and PO total. PO schemas often include an enum for approval status.
Delivery notes (goods receipts). Confirmation of delivery used for two- and three-way matching. Key fields: delivery note number, delivery date, PO reference, vendor name, receiving address, line items (item code, description, quantity delivered), and receiver signature or attestation. ADE's attestation chunk type detects signatures and stamps as distinct structured elements.
Remittance advice. The payment notification sent by buyers to vendors. Key fields: payment date, payment method, payer entity, payee entity, bank or payment reference, and a table of invoices being paid (invoice number, invoice amount, discount taken, amount paid).
Each schema is defined once and applies across all vendors without modification. See the Schema Wizard Playground for interactive schema definition and validation against real documents.
Three-Way Matching with Grounded Extraction
Three-way matching (verifying that the invoice, PO, and delivery note agree on items, quantities, and prices) requires that the values extracted from each document are traceable to their source locations. ADE returns bounding-box citations with every extracted field, linking each value to its exact page and coordinates in the source document. When a discrepancy is found during matching, the AP system can surface the exact location in each of the three documents where the conflicting values appear, reducing the time to resolve exceptions from full-document re-reads to targeted source verification.
Confidence scores on extracted fields provide the triage signal: high-confidence fields route to automated matching; low-confidence fields route to a reviewer with the source citation already populated. This combination of confidence routing and source-grounded citations is what makes straight-through processing economically viable at AP volume.
Multi-Language and Multi-Currency AP Processing
Global AP operations receive invoices in the language of the vendor's country of operation. ADE's supported languages include non-Latin scripts and mixed-language documents, processed by the same visual-first parsing architecture without separate models per language. Currency fields in the extraction schema use typed numeric values with a separate currency code field, handling VAT, GST, and regional tax conventions by schema description rather than hardcoded rules.
Integration into AP Systems
The Extract API returns typed JSON matching the customer-defined schema. Line-item arrays, numeric totals, date fields, and vendor identifiers are returned in structured form ready for direct database writes, ERP integration, or AP automation platform APIs, without an intermediate transformation layer. For high-volume batch processing, the Parse Jobs API handles documents up to 1 GB asynchronously, supporting overnight batch runs that process the full prior-day invoice intake in a single job queue. The Python library and TypeScript library provide the client-side integration layer.
FAQ
Does ADE require a separate template or configuration for each vendor? No. ADE's visual-first parsing handles layout variation across vendors without per-vendor templates. The extraction schema defines which fields to extract by name and type, not by coordinate position. A new vendor is onboarded by submitting a sample invoice to the Schema Wizard Playground and confirming the existing schema captures the correct fields from the new layout. No schema changes are required for new vendors whose invoices contain the same logical fields.
How does ADE handle invoices with variable numbers of line items? The line-items field in the extraction schema is defined as a typed array. ADE extracts all rows present in the line-item table regardless of count, returning them as an array of objects with consistent field names (description, quantity, unit price, line total). There is no minimum or maximum row count encoded in the schema, so invoices with 2 line items and invoices with 200 line items use the same schema and return the same output structure.
What happens when a field on an invoice is ambiguous (for example, when "Total" could mean subtotal or final amount)? Field descriptions in the extraction schema guide the model on disambiguation. A description such as "The final total amount payable including all taxes and discounts, after all adjustments" distinguishes the final total from line totals and subtotals. Per schema best practices, specific and descriptive field definitions are the primary mechanism for accurate extraction on semantically ambiguous fields. Where genuine ambiguity remains, the confidence score for that field reflects the uncertainty and routes it to review.
Can ADE perform three-way matching directly, or does it only extract data for matching? ADE extracts structured data from each of the three document types (invoice, PO, and delivery note) with bounding-box citations on every field. The matching logic (comparing PO quantities to delivery quantities to invoice quantities) runs in the calling application, not in ADE. ADE's role is to ensure that the extracted values are accurate and traceable, so that discrepancies found during matching can be resolved by navigating to the exact source location in each document.
How are scanned invoices handled compared to native digital PDFs? ADE's visual-first architecture processes scanned invoices and native digital PDFs using the same parsing model. Scan quality affects confidence scores on extracted fields: lower-quality scans produce lower confidence on affected fields, which routes them to human review rather than passing silently wrong values downstream. See confidence score documentation for current scope and field-type limitations.