Rows
Line items stay line items
Descriptions, quantities, units, tax rates, and row totals can be returned in structured arrays instead of merged strings.
Invoice line item extraction API
AP data extraction API
Get line items into JSON without flattening the most important part of the invoice.
Many OCR tools can find the invoice total. Fewer return line items in a shape finance systems can actually trust. LeapOCR helps teams extract invoice rows, units, pricing, taxes, and totals into schema-fit JSON while keeping the page reviewable.
Why teams use this
Extract item descriptions, SKUs, quantities, units, unit prices, taxes, and row totals.
Support line-item tables across modern invoices, scanned PDFs, and mixed vendor layouts.
Return a stable array your AP or ERP workflow can validate before posting.
Line-item extraction request
The useful result is a row array, not a paragraph of OCR text that still has to be split apart downstream.
Invoice line-item request
{ "url": "https://example.com/invoice.pdf", "file_name": "invoice.pdf", "format": "structured", "instructions": "Extract vendor metadata, invoice totals, and every invoice line item with quantity, unit price, tax, and line total.", "schema": { "type": "object", "properties": { "invoice_number": { "type": "string" }, "vendor_name": { "type": "string" }, "line_items": { "type": "array" } } }}
Why it works
Why line-item extraction matters more than headline OCR
Finance workflows usually break at the table level, not the invoice-title level.
Normalization
The output can fit AP workflows
The schema can reflect how your AP or ERP system expects line items, not how the PDF happens to present them.
Review
Keep the invoice readable for humans too
Markdown helps reviewers verify a row-level discrepancy without losing the structured extraction path.
What you control
What teams usually want from invoice rows
The fields below are the ones most likely to decide whether the invoice can be posted without manual repair.
sku
Optional field
Product or service identifiers
Where vendors expose SKUs or service codes, teams often want them captured with the line item for downstream mapping.
qty
Required for AP
Quantity, unit, and unit price
These fields are what let finance systems validate the row instead of treating the invoice as one total amount.
tax
Validation field
Tax rate and row total
Capturing tax and row totals helps AP teams reconcile invoice lines before posting or approval.
header
Context block
Vendor and invoice metadata
Line items are only useful when the invoice identity and vendor context travel with them.
Examples
Two common invoice row workflows
Most teams either need row-ready JSON for posting logic or a readable invoice table for review and exception handling.
Posting pipeline
Return line items for AP and ERP writeback
This is the common path for teams that want invoice rows to survive extraction without another parser or manual data-entry pass.
Line-item result
json
{ "invoice_number": "INV-8813", "vendor_name": "Harbor Office Supply", "invoice_total": 610.0, "line_items": [ { "description": "Consulting service", "quantity": 1, "unit_price": 100.0, "tax_rate": 10.0, "line_total": 100.0 } ]}
Exception handling
Keep a readable invoice table for row-level checks
When AP teams need to verify a questionable row, markdown provides a cleaner review surface than raw OCR text.
Markdown excerpt
md
# Invoice INV-8813- Vendor: Harbor Office Supply- Invoice total: 610.00## Line items| Description | Qty | Unit price | Tax | Line total || --- | ---: | ---: | ---: | ---: || Consulting service | 1 | 100.00 | 10% | 100.00 |
FAQ
Questions teams ask before wiring this up
Straight answers for teams evaluating how this workflow fits into production.
Can LeapOCR return invoice line items as structured JSON?
Yes. The workflow is designed to return line items as arrays with row-level values like quantity, unit price, tax, and totals.
Why do line items need their own OCR page?
Because many tools can find totals, but line-item tables are where real AP workflows usually break. This page targets that deeper extraction problem directly.
Can line-item extraction still support human review?
Yes. Markdown stays useful for row-level QA and exception handling while JSON powers the downstream workflow.
Ready to test
Test whether your invoice rows survive extraction in a usable shape
The best evaluation is simple: run a real invoice with line items and see whether the result is ready for AP or still needs another parsing layer.