Extract Custom Fields From Invoices: Practical Guide

You can extract custom fields from invoices when the value is visible on the document or can be reliably inferred from the invoice contents. Fields that depend on accounting policy, supplier history, ERP master data, contract terms, or cross-document calculations should be handled with post-extraction rules, review flags, or downstream system logic.

That distinction matters because "custom field" can mean two very different things. It might mean a column the invoice already contains, such as purchase order number, delivery address, project reference, payment terms, or tax ID. It might also mean a business decision the invoice only hints at, such as GL code, branch allocation, client billing category, or whether the invoice should be routed for approval.

The reliable way to extract custom fields from invoices is to sort each requested column before you write the prompt:

1. Directly visible fields that appear on the invoice.
2. Line-item fields that appear inside the invoice table and need row structure.
3. Inferred or contextual fields that can be assigned from the invoice contents when the rule is stable.
4. Derived or conditional fields that follow an explicit rule, calculation, or exception condition.
5. Downstream-only fields that require business data outside the invoice.

Default invoice extraction usually covers invoice number, date, vendor, subtotal, tax, and total. Custom invoice data extraction begins when you ask for columns beyond that default set: branch, department, client code, project, shipment number, purchase category, tax treatment, review status, or import-ready values for an accounting system.

The goal is not to make the extractor guess harder. It is to give each field the right job. Let extraction read and structure what the invoice supports. Let spreadsheets, validation rules, ERP lookups, and human review handle the decisions that need context the invoice does not contain.

Start with fields that are actually on the invoice

The safest custom fields are the ones the invoice already gives you. Purchase order number, job number, delivery address, service period, payment terms, supplier VAT ID, customer account number, ship-to branch, and project reference are good candidates because the extractor can point to something in the document.

Before adding those columns, separate them from the ordinary AP fields. If the workflow only needs invoice number, invoice date, vendor, subtotal, tax, total, and due date, a default schema may be enough. A custom field is a column that changes the usefulness of the output for your workflow, not a renamed copy of a field every invoice parser already expects. For the baseline set, use standard supplier invoice fields for bookkeeping as the reference point, then define what your process needs beyond it.

Invoice field mapping should preserve the source meaning. If an invoice shows "Customer Ref," do not automatically map it to "Project Code" unless that is how the supplier actually uses the field. If an invoice shows both "Ship To" and "Bill To," decide which one drives branch reporting before the batch runs. If a supplier prints a job number in the description line rather than a header field, treat it as a field with a source-location rule, not as a generic note.

Clear column names help more than clever prompts. "Branch from delivery address" is stronger than "branch." "Supplier VAT number" is clearer than "tax number." "Customer PO number" is safer than "reference." The column name should tell the extractor what evidence to look for and tell the reviewer what the value is supposed to mean.

Treat line items as rows, not just extra columns

Line-item custom fields are visible on the invoice, but they behave differently from header fields. SKU, item code, description, quantity, unit price, discount, tax rate, service period, department, project, and cost center only make sense if each value stays attached to the correct invoice row.

That means the first output decision is row shape. If the spreadsheet is one row per invoice, line-item detail has to be summarized, nested elsewhere, or omitted. If the spreadsheet is one row per line item, header fields such as supplier name, invoice number, invoice date, and total may repeat on each row so the line can stand on its own in an import or workpaper.

The common failure is asking for line-item fields without saying how the rows should work. A prompt that asks for "invoice number, vendor, item, quantity, price, department, and total" can produce a table, but it has not defined whether the total belongs to each invoice, each line, or a validation column. The output schema should make that explicit before processing begins.

Some line-item values are read directly. Others are derived. A line net amount might be quantity multiplied by unit price, a variance flag might compare line total to expected line total, and a taxable status might depend on a line tax rate. Those can be useful, but they need the same caution as any calculated fields in invoice extraction: use them when the formula is explicit, keep the source fields available, and flag mismatches rather than hiding them.

For AP imports, row structure matters as much as field accuracy. A correct item code attached to the wrong description is still wrong. A complete table with missing tax rates may be easier to review than a confident-looking table that silently fills gaps.

Use rules only when the invoice supports them

Inferred fields can be reliable when the invoice contains enough evidence and the rule is stable. If each delivery address belongs to one branch, the extractor can assign branch from the address. If freight lines always contain "freight," "shipping," or a carrier name, the extractor can classify those lines as freight. If a supplier uses a consistent project code format, the extractor can pull it from a reference field or description.

Conditional fields work the same way: the rule has to be explicit. You can ask for a review flag when the purchase order number is missing, when tax is present but no tax ID appears, when the invoice total does not equal subtotal plus tax, or when a supplier name should map to a controlled category only if that allowed mapping list is supplied. That is conditional invoice data extraction, not guesswork.

Downstream-only fields are different. GL account, final tax treatment, intercompany status, approval route, and supplier risk status may depend on chart-of-accounts policy, ERP master data, contracts, supplier history, or prior invoices. If that context is not on the invoice or in the prompt, the extraction output should not pretend to know it.

Use uncertainty handling deliberately:

• Leave a field blank when the value is absent and a blank is acceptable for the workflow.
• Use "unknown" when the reviewer needs to distinguish a missing value from an empty optional field.
• Add a review flag when the value might be present but ambiguous, or when the field affects posting, payment, tax, or routing.
• Keep allowed values short and controlled when the output feeds an import.

For deeper prompt construction, the same principles belong in the field instructions, not in a vague request to "extract all relevant data." Strong invoice data extraction prompt design names the column, states where the evidence should come from, defines allowed values if needed, and tells the extractor what to do when the value is missing or uncertain.

Invoice Data Extraction is built for this kind of custom invoice data extraction: users describe the fields, formats, and review rules they need in a natural language prompt, save reusable prompts for repeat work, and download structured Excel, CSV, or JSON without building supplier-specific templates.

Design the output before you run a batch

Output format is not just a download preference. It changes how custom invoice columns should be named, flattened, nested, validated, and reviewed.

Excel is usually the best working format when people need to inspect the result. It can hold review columns, formulas, filters, conditional formatting, and side-by-side checks against source fields. If a bookkeeper needs to approve category suggestions or a controller wants to review tax treatment, Excel gives the custom fields room to be checked before they move into the accounting system.

CSV is stricter. It works best for stable flat columns and import-safe values: one date format, one decimal convention, predictable blank handling, controlled category names, and no nested line-item structure unless each line becomes its own row. If the output is going into an ERP, accounting platform, or upload template, define the invoice CSV output rules before running the batch rather than cleaning every file afterward.

JSON is better when the structure matters more than a flat spreadsheet. It can preserve nested line items, separate header-level fields from row-level fields, and carry field groups for an automation or API workflow. That makes JSON useful for technical workflows, but it also means the field design should specify which values belong at invoice level and which belong inside each line item.

The same extraction prompt can lead to very different outputs depending on this choice. Invoice Data Extraction supports structured Excel, CSV, and JSON downloads from the prompt-based workflow, so the practical question is not whether a custom field can appear somewhere. It is where the field should live so the next step can use it without manual repair.

Test custom fields by field and supplier pattern

A parsed-looking invoice is not proof that custom extraction is ready for recurring work. The output can look neat while one field fails for a specific supplier layout, one line-item table drops discount rows, or one conditional flag works only when the invoice uses familiar wording.

Testing should be field-specific. Pick representative invoices from the suppliers, layouts, languages, and document types you expect to process. For each important custom field, compare the extracted value with the expected value. Track whether the issue is a missing source value, a field-name ambiguity, a line-item row problem, a formatting issue, or a rule that needs business context.

Research on field-level invoice extraction evaluation metrics makes the same point at a technical level: invoice extraction quality should be evaluated at field and line-item level, including exact or relaxed field matching, line-item row assignment, table completeness, and robustness across different suppliers and layouts. In practical terms, do not judge a batch by whether the invoice "looked parsed." Judge it by whether the fields your workflow depends on are right.

Use the results to improve the field design, not to add broad instructions. If branch fails only when the delivery address is absent, add a blank or review rule for that field. If line descriptions are correct but tax rates shift rows, tighten the line-item output structure. If GL hints depend on supplier master data, move that step out of extraction or provide an explicit allowed mapping.

High-risk fields deserve review flags even when extraction is mostly reliable. Tax treatment, GL hint, department routing, missing purchase order number, supplier mismatch, total variance, and calculated exceptions can affect payment, posting, or compliance. A visible exception column is safer than a silent guess.

A practical field design checklist

Use this sequence before processing a real invoice batch:

1. List every custom column the workflow wants, including review flags and import-only fields.
2. Mark each field as directly visible, line-item, inferred, derived or conditional, or downstream-only.
3. For every visible field, name the source evidence the extractor should use.
4. For every inferred field, write the rule that makes the inference safe.
5. For every conditional field, define the condition, allowed output values, and review behavior.
6. For every downstream-only field, decide whether it belongs in a spreadsheet formula, ERP lookup, approval workflow, or human review step.
7. Choose the output shape: Excel for review, CSV for flat imports, or JSON for structured automation.
8. Define blanks, "unknown," and review flags before the batch runs.
9. Test representative suppliers and layouts by field, not just by invoice.
10. Keep source fields visible when a derived value affects posting, tax, routing, or payment.

The useful boundary is simple: extraction should read, structure, and apply explicit rules to what the invoice supports. Accounting policy, master-data lookup, supplier history, contract terms, and cross-document decisions need explicit downstream handling.