Ampwise AI
    Back to blog

    PDF Invoice Field Mapping: How to Map Fields to Your ERP

    PDF invoice field mapping is the process of linking each piece of data on an invoice, such as the invoice number, the due date or a line-item quantity, to the matching field in your ERP or accounting system. Get the mapping right and invoices flow into your system with little retyping. Get it wrong and you spend your week fixing totals, vendors and dates by hand. This guide covers what to map, how to handle different layouts, scanned files and custom fields, and how to check the result before anything is posted.

    Ampwise
    Move Invoice Data Into Your ERP
    Ampwise processes invoices from PDFs, scanned documents, and free-text emails, helping reduce manual data entry in email-to-ERP workflows.
    Explore Ampwise

    TL;DR

    • Field mapping connects what is printed on an invoice (source) to what your ERP expects (destination), including data type and rules for required or optional values.
    • A good mapping lists more than two names: it also records data type, sample value, country and whether the field is mandatory.
    • Different vendor layouts, scans and free-text emails break fixed position or template-based mapping, so map by meaning, not by coordinates.
    • Validate every mapped value (totals, dates, vendor, PO match) before it reaches the ERP, and keep a human approval step for exceptions.
    • Mapping data is not the same as customizing how your own invoice PDF looks. They are two separate jobs.

    Table of Contents

    What PDF invoice field mapping actually means

    An invoice is a human-readable document. Your ERP is a database with named fields, types and rules. Mapping is the translation table between the two: “Invoice No.” on the PDF goes to the vendor invoice reference field, “Total Due” goes to the gross amount, “Net 30” becomes a payment term code.

    There are two directions, and people often mix them up:

    1. Inbound mapping (reading invoices you receive). You take a vendor’s PDF, pull out the values, and write them into your ERP’s payable or purchase records. This is the focus of this article.
    2. Outbound mapping (generating invoices you send). Your system’s data fields are placed onto an invoice template, or exported to an e-invoice format. Many of the top search results for this keyword are about this direction, for example showing custom fields on an invoice PDF.

    Both need a clear list of fields and rules. The difference is who controls the format. When you generate invoices, you do. When you receive them, every supplier does something different.

    The fields most teams map

    The core set is surprisingly stable across systems. One e-invoicing vendor’s documentation shows its default mapping to the EN 16931 e-invoice semantic model, which covers seller and buyer names and addresses, invoice number and dates, payment terms, VAT totals, the amount due, and line-item identifiers, descriptions, quantities, units and net amounts. That list is a handy checklist even if you never touch an e-invoice format.

    Here is a practical grouping for accounts payable:

    Group Typical fields Why it matters
    Header: parties Supplier name, supplier address, tax ID, buyer name, ship-to Vendor matching and duplicate detection
    Header: document Invoice number, invoice date, due date, currency, PO number Duplicate checks, three-way matching, aging
    Header: money Net total, tax or VAT total, gross total, amount due Reconciliation, posting
    Payment Payment terms, bank details, early-payment discount Cash planning, payment runs
    Line items Item or SKU, description, quantity, unit, unit price, line net amount Matching to PO and goods receipt
    Optional or custom Cost center, project code, delivery note number, contract reference Coding and approvals

    Payment terms deserve extra attention because they drive when cash leaves your account. Terms such as net 30 or a discount for early payment appear in different wording on every supplier’s invoice, and an invoice payment terms guide shows how varied the wording and the optional business-process details on invoices can be. Your mapping needs a rule that turns free wording into one consistent term in your ERP.

    How to identify and match fields in a PDF invoice

    There are three common ways to find a value on a PDF and connect it to a system field. They differ in how much they tolerate layout changes.

    1. Position-based zones

    You draw a box around where “Invoice Number” usually sits and tell the software to read that box. It works for one supplier with one layout. It fails the moment the supplier updates their template, adds a logo, or sends a two-page invoice.

    2. Template or rule-based mapping

    You build a template per supplier, using anchor words (“Invoice No”, “Date”) and rules. This is sturdier than raw zones, but you maintain one template for every vendor and every variant. With hundreds of suppliers, the maintenance becomes a job in itself.

    3. Meaning-based extraction

    AI models read the document the way a person does: they recognize an invoice number because of its role and context, not because of its position. This approach does not require a template per supplier, and it can also read emails, scans and Excel attachments. We cover how it works in more detail in our guide to PDF data extraction to ERP, and if you want to test options with your own files, our benchmark approach with 50 to 100 real documents is a good starting point.

    Whichever method you use, the mapping step itself stays the same: for every extracted value, decide the destination field, the format and the rule for when it is missing.

    Build a mapping specification, not just a list of names

    Most mapping projects start with a two-column spreadsheet: PDF label on the left, ERP field on the right. It breaks quickly. Documentation on one compliance network’s canonical invoice model shows that a useful field mapping records more than source and destination names: the document version, country, data type, sample value, legal path, and whether the field is mandatory or optional under which conditions.

    You do not need the legal path for every internal project, but the principle carries over. A workable specification has at least these columns:

    • Source label(s): every wording seen in practice (“Invoice No.”, “Inv #”, “Rechnungsnummer”).
    • Destination field: the exact ERP field or API property.
    • Data type and format: text, integer, decimal, date, with the expected format (for example, MM/DD/YYYY vs. DD.MM.YYYY).
    • Required, optional or conditional: for example, PO number required for stock purchases but not for services.
    • Sample value: one real example that a colleague can check against.
    • Transformation rule: strip currency symbols, convert decimal commas, map “Net 30” to term code 30D.
    • Country or entity: tax fields differ between US sales tax, VAT and GST.

    If your mapping lives in code, it helps to define the target structure up front. Developer documentation for an AI agent framework recommends a typed schema as a data contract before downstream integration, and handling missing or optional fields explicitly instead of letting them pass through as blanks. The same idea applies without code: write down what a valid record looks like before you automate anything.

    Handling custom fields and different layouts

    Two things cause most mapping headaches: fields that only your company uses, and layouts that differ per supplier.

    Custom fields

    Cost centers, project numbers, internal order references and contract IDs rarely appear in a standard field list. To handle them:

    1. Decide which are truly needed for posting or approval. Map those first.
    2. Define where the value comes from. It may be printed on the invoice, but it may also come from the matching PO or from the sender’s email.
    3. Mark them conditional. A project code may be mandatory only above a certain amount or for certain vendors.
    4. Give them a default or an exception path, such as routing to a named approver, rather than silently leaving them empty.

    Varying layouts

    Suppliers put the invoice number top left, top right or in a footer. Some show tax per line, others only in a summary. Some send credit notes that look like invoices. Map by meaning and add a document type check: invoice, credit note, pro forma or reminder. A pro forma invoice posted as a real invoice is an expensive mistake.

    Line items need the same care. Multi-page tables, wrapped descriptions and subtotal rows can all be read as extra lines. Check that the sum of the mapped lines equals the header net total. If it does not, something was split or merged wrongly.

    Scanned PDFs and image-based invoices

    A scanned PDF is a picture of text. Before any mapping can happen, the text has to be recognized. That adds a second source of errors: a smudged “8” read as “3”, a decimal point lost in a fax. When you plan for scans:

    • Expect lower confidence on amounts, dates and IDs, and mark these fields as high-risk for review.
    • Cross-check numbers. Net plus tax should equal gross. Line totals should add up to the header.
    • Keep the original file linked to the ERP record so approvers can see what the extraction saw.
    • Test with your worst documents, not your best. Include skewed phone photos, stamped pages and handwritten notes.

    If your invoices arrive by email rather than through a portal, the attachment, the email body and sometimes a second attachment all matter. Our guides on Outlook PDF invoice processing and Gmail PDF invoice processing show how mixed formats can be handled in the inbox itself.

    Validate mapped data before it reaches the ERP

    Mapping puts a value in a field. Validation tells you whether that value is believable. Build these checks in, in this order:

    1. Format checks. Dates are real dates, amounts are numeric, currency codes are valid.
    2. Arithmetic checks. Lines sum to net, net plus tax equals gross, tax rate times net matches tax amount within a rounding tolerance.
    3. Master data checks. The supplier exists in your vendor list, the bank details match what you have on file, the tax ID is plausible.
    4. Duplicate checks. Same supplier, same invoice number, same amount should be flagged, even when the file name differs.
    5. Business document checks. The PO exists, is open, and the price and quantity are within tolerance. Our piece on validating purchase orders before ERP release describes three checks that catch most problems.
    6. Human review for exceptions. Anything that fails a check goes to a person with the original document next to the extracted data. Everything that passes can be approved in one click.

    The point of this staged design is that people spend their time on the 10 or 20 percent of invoices that are odd, not on retyping all of them. For a broader view of field-level accuracy, see our article on invoice data extraction for AP.

    Keeping mappings healthy as formats change

    A mapping is not a one-time project. Suppliers change templates, you onboard new vendors, your ERP gets a new custom field, and tax rules move. A few habits keep things stable:

    • Version your specification. Note what changed, when and why.
    • Track exceptions by field. If “due date” fails review often for one supplier, that is a mapping rule to fix, not a person to blame.
    • Review a sample monthly. Pull 20 posted invoices and compare them with the originals.
    • Add new wording to the source labels when a supplier uses a new term, so the rule improves for everyone.
    • Pilot before you scale. A short pilot on real email and scan volume shows where the mapping is weak. Our invoice automation guide for AP teams outlines a 2 to 4 week approach.

    Mapping data vs. customizing the invoice PDF

    Searching this topic returns many forum threads about getting a custom field to show on an invoice PDF, or removing blank fields from a template in an accounting or CRM system. That is layout customization: you decide which data appears where on a document you send. It is useful, but it is a different task from field mapping.

    Data field mapping Invoice PDF customization
    Goal Move invoice data between systems Control how a document looks
    Typical user AP, finance operations, integrators Billing admin, designer
    Main risk Wrong or missing values in the ERP Missing or misplaced fields on the printout
    Key question Which source value goes to which destination field? Which field shows in which place?

    If you issue invoices as well as receive them, you will do both. Just keep the two specifications separate so a layout tweak never changes how data is stored.

    Our perspective on invoice mapping

    We see the same pattern in almost every company with heavy email traffic: the invoice is not the problem, the handoff is. Somebody opens an email, opens the PDF, finds the numbers and types them into the ERP. Every step adds delay and a chance for error.

    Our view is that mapping should adapt to the documents, not the other way around. Asking suppliers to use a standard template rarely works, and building a template per supplier does not scale. That is why we built Ampwise to work without templates and to read PDFs, scanned documents, Excel files and free-text emails directly from Outlook or Gmail. The extracted values are validated and mapped to your existing ERP, and your team approves verified data with one click. No retraining, no change to how suppliers send invoices.

    We say our solution can reduce manual data entry by up to 90%, and our customers aim for a return within three months. The real win, though, is relief: less copying, fewer corrections, and more time for work that needs judgment.

    Evert

    See it on your own invoices

    If your team receives invoices, orders and confirmations by email and keys them into an ERP by hand, Ampwise can take over the reading, labeling, validating and entering. It works inside Outlook and Gmail, handles PDFs, scans and Excel without templates, and connects to common ERP systems. You stay in control through one-click approval of verified data. Learn more on the Ampwise product page.

    Ampwise

    You can also see how the email-to-ERP flow fits together on our home page, or read how teams approach unstructured document processing when choosing between pipelines and vision-language models.

    A short checklist to start

    1. Collect 50 real invoices from at least 10 suppliers, including scans and credit notes.
    2. List every field your ERP needs for posting, approval and matching.
    3. For each field, write the source labels, data type, rule and whether it is mandatory.
    4. Decide your validation checks and your tolerance for rounding.
    5. Route exceptions to a named person with the original document visible.
    6. Measure accuracy per field, not per document, and fix the weakest field first.

    This same discipline applies beyond invoices. If you also import spreadsheet orders, our guide on Excel order import automation uses the same specification approach, and the principles in email data mapping patterns transfer to CRM and marketing data too.

    FAQ

    What is PDF invoice field mapping?

    It is the process of defining which value on a PDF invoice goes into which field of your ERP or accounting system. A complete mapping also covers the data type, format, transformation rules and whether a field is required.

    Which invoice fields should I map first?

    Start with the ones needed to post and pay: supplier, invoice number, invoice date, due date, currency, PO number, net, tax and gross totals. Then add line items and payment terms, and finally custom fields such as cost center or project code.

    Can I map invoices without building a template for each supplier?

    Yes. Meaning-based AI extraction reads the document by context instead of position, so a new supplier layout does not need a new template. You still need a specification of target fields and validation rules, and you should test it on your own documents first.

    How do I catch wrong values before they hit the ERP?

    Check formats, make sure lines add up to totals, confirm the supplier and bank details against master data, flag duplicates and match to the PO. Send anything that fails to a reviewer who sees the original file beside the extracted data.

    Sources

    📅 Book an Ampwise AI demoBack to blog