Invoice JSON Format

Last updated July 2026

An invoice JSON format is a structured, machine-readable representation of an invoice, with named fields for the header data (invoice number, dates, vendor, buyer), the totals (subtotal, tax, total), and an array of line items. There is no single mandated standard, but a good invoice JSON schema keeps header fields flat, holds line items in an array of objects, uses ISO date and numeric formats, and stays consistent across every document so your code can rely on it. Below is a clean example you can copy.

If you are wiring invoices into an accounting system, an ERP, or a database, JSON is usually the format you want. It is easy to parse in every language, maps cleanly to objects, and travels well over APIs. The trick is designing a structure that is stable and complete enough to handle real invoices, including multiple line items and tax. Here is a practical format, the fields that matter, and how to generate it from a PDF.

What should an invoice JSON contain?

A complete invoice JSON has three layers. First, header fields that identify the document: invoice number, issue date, due date, and a currency. Second, party information for the seller and buyer: name, address, and tax or account identifiers. Third, the money: an array of line items, each with a description, quantity, unit price, and amount, followed by summary totals for subtotal, tax, and the grand total. Getting all three layers right is what makes the JSON usable downstream instead of just a partial capture of the page.

A clean invoice JSON example

Here is a straightforward, real-world invoice JSON structure. It keeps header fields flat, groups the parties, and puts line items in an array so an invoice with one row or fifty rows uses the same shape.

{
  "invoice_number": "INV-4821",
  "issue_date": "2026-07-15",
  "due_date": "2026-08-14",
  "currency": "USD",
  "vendor": {
    "name": "Acme Supply Co.",
    "address": "120 Market St, Austin, TX 78701",
    "tax_id": "74-1234567"
  },
  "bill_to": {
    "name": "Northwind LLC",
    "address": "500 Pine Ave, Seattle, WA 98101"
  },
  "line_items": [
    {
      "description": "Steel brackets, 4 in.",
      "quantity": 200,
      "unit_price": 3.50,
      "amount": 700.00
    },
    {
      "description": "Freight",
      "quantity": 1,
      "unit_price": 85.00,
      "amount": 85.00
    }
  ],
  "subtotal": 785.00,
  "tax": 64.76,
  "total": 849.76,
  "payment_terms": "Net 30"
}

Rules for a reliable invoice JSON schema

A few design choices make the difference between JSON your code trusts and JSON it constantly guards against.

• Use consistent field names. Pick invoice_number or invoiceNumber and never mix them. Consistency lets you parse every invoice with one code path.
• Keep numbers as numbers. Store amounts as numeric values, not strings with dollar signs, so you can total and compare them without cleanup.
• Use ISO 8601 dates. Format dates as YYYY-MM-DD so they sort and parse the same everywhere, regardless of the invoice's printed style.
• Always include the currency. A total means nothing without its currency, especially if you handle international vendors.
• Put line items in an array. Never flatten them into item_1, item_2 fields. An array handles any number of rows and is far easier to iterate.
• Include totals explicitly. Store subtotal, tax, and total as their own fields rather than expecting consumers to recompute them, so you can validate the math.

How to convert a PDF invoice to JSON

You have three broad options, depending on volume and skill. You can copy fields by hand into a JSON template, which is fine for the occasional invoice and hopeless at scale. You can write code with a PDF library plus your own parsing logic, which works for a single fixed layout but breaks across vendors. Or you can use an AI extraction tool or API that reads any invoice layout and returns structured JSON directly, which is what most teams settle on once they process more than a handful. The convert invoice to JSON page walks through the no-code path, and the invoice data extraction API returns the JSON straight to your pipeline.

Validating invoice JSON before you use it

Structured output is only useful if it is correct. Two cheap checks catch most problems. First, verify the arithmetic: line-item amounts should sum to the subtotal, and subtotal plus tax should equal the total. If they do not, flag the invoice for review. Second, check that required fields are present and non-empty, since a missing invoice number or date will break your downstream records. When you extract at volume, the same structured discipline applies to any data you pull from unstructured sources. Teams that also collect data from the web often pipe it through a web scraping API that returns clean, LLM-ready data, then run the same presence-and-consistency checks before loading it into a warehouse.

Why JSON beats a spreadsheet for automation

Excel and CSV are perfect when a human is the next reader. JSON wins when software is. It preserves the nested structure of an invoice, so line items stay grouped under their invoice instead of being flattened into repeated rows. It carries types, so a number stays a number. And it moves cleanly through APIs and message queues. If your goal is to post invoices into an ERP, trigger an approval workflow, or store them in a document database, JSON is the natural format. If a person just needs to review the numbers, export to a spreadsheet instead.

The bottom line

A good invoice JSON format is flat where it can be, nested where it must be, typed correctly, and consistent across every document. Use the example above as a starting schema, validate the totals and required fields, and generate the JSON automatically rather than by hand once you are past a few invoices a week. To turn a PDF or scanned invoice into this structure without writing a parser, try the tool at the top of this page or read the invoice to JSON guide.