Field-level ERP sync means an AP platform reads and writes every individual field your ERP uses to code an invoice, not just the handful needed to create a record. That includes the dimension values, entity structure, tax treatment, and line-level detail your ERP validates against. The distinction matters because an invoice can post successfully and still be coded wrong. Field-level ERP sync is what determines whether your AP team codes inside the platform once, or codes twice: once in the tool, and again in the ERP after the export.
This is one of the least examined questions in an AP evaluation, and one of the most predictive of how your close will go.
What field-level sync actually means
Three properties have to be true for a sync to be field level rather than record level.
- Coverage. The platform can read and present every field your ERP considers relevant to an AP transaction, including custom fields, not a fixed subset.
- Direction. The sync runs both ways, so master data changes in the ERP appear in the AP platform and coded transactions flow back without a manual re-key.
- Constraint awareness. The platform enforces the same relationships the ERP enforces, so an invalid combination cannot be selected in the first place.
A sync that satisfies the first property but not the third produces a familiar problem: complete dropdowns that let a coder pick a value the ERP will reject.
Header-level vs line-level coding
Header-level coding assigns one set of values to an entire invoice. Line-level coding assigns values per line. The gap between them is where most coding rework lives.
| Header-level coding | Line-level coding | |
|---|---|---|
| What gets coded | One GL account, one entity, one set of dimensions per invoice | Distinct account, dimensions, and tax treatment per line |
| Splits across departments or jobs | Handled outside the platform, usually in a spreadsheet or a manual ERP journal | Handled in the invoice itself |
| PO matching | Matches invoice total to PO total | Matches each line to the corresponding PO or receipt line |
| Where errors surface | In the ERP or during reconciliation | While the invoice is still open |
| Typical failure mode | A correct total sitting on the wrong accounts | Slower initial setup, more configuration to maintain |
A single freight invoice split across four cost centers is the whole test. If it takes a spreadsheet, the sync is not line level, whatever the marketing says.
What each ERP expects on an AP invoice
Coding requirements are a property of the ERP, not the AP tool. Before you assess any platform, write down the fields your own system requires. Common structures by ERP:
| ERP | Core AP coding structure |
|---|---|
| NetSuite | Subsidiary, class, department, location, GL account, custom segments and custom fields, tax treatment (SuiteTax or legacy), posting period, line-level PO matching |
| Acumatica | Company or tenant, branch, subaccount, project, task, cost code, GL account, line-level PO and purchase receipt matching |
| Microsoft Dynamics 365 Finance & Operations | Legal entity, financial dimensions, GL account, with valid dimension values constrained by the selected account structure |
| Microsoft Dynamics 365 Business Central | Company within the tenant, header and line-level dimensions, dimension-related GL filtering, posting groups, tax setup |
| Microsoft Dynamics GP | GL account segments, distribution types and distribution table behavior, tax schedules and tax detail IDs, payment terms and discount tracking |
| Oracle Fusion | Ledger, business unit, legal entity, GL combination code, distribution sets, project and task, header and line flexfields, cross-validation rules |
| QuickBooks Online | Line-level GL account, class and location per line, items and parent or child item hierarchies, customer or job context, inclusive and exclusive tax handling |
| QuickBooks Desktop | GL account, class at header and line, Customer:Job for job costing, items and item receipts, billable flags, custom fields to line level |
| Sage 300 CRE | Job, cost code, cost type, commitment, retainage, GL account, across multiple companies |
| DealerTrack DMS | Company or rooftop, control number, purchase journal, GL account, with isolation between stores |
Print your own version of that row. It becomes the demo script for every vendor conversation, and it is the fastest way to expose a shallow integration.
Field count is a weak proxy
Vendors sometimes quote a number of supported fields. Treat it as context, not evidence. What matters is whether the specific fields you use are covered, whether they are covered at line level, and whether the platform respects the dependencies between them.
Dependencies are the part that gets missed. Real ERP structures cascade:
- In multi-subsidiary environments, the subsidiary selection should filter which departments, classes, and locations are even offered.
- In project-based environments, the chain runs branch, then project, then task, then cost code, with each step narrowing the next.
- In dimension-driven ERPs such as Dynamics 365 Finance and Operations, the selected GL account should determine which dimension values are valid.
A platform that syncs all the values but none of the relationships produces long dropdown lists and confident wrong answers. This is why teams evaluating how to automate invoice coding should test filtering behavior specifically rather than assuming that field presence equals field logic. The same applies to recurring splits, where allocation templates that speed up GL coding only help if the underlying dimensions are available at line level.
Why this compounds with complexity
At one entity and a flat chart of accounts, header-level coding is survivable. The math changes as structure grows.
Each new entity multiplies the dimension combinations a coder has to get right. Each new project or job adds a cascade. Each acquisition brings a chart of accounts that does not match the one you have. What was a rounding error at three entities becomes a recurring close item at fifteen, which is the pattern teams describe when they start running AP across separate companies and multiple ERP systems.
Line-level matching is where it hits hardest. Partial receipts, multi-PO invoices, and price variances all require line detail to resolve. Without it, three-way invoice matching degrades into a total-to-total check that misses exactly the discrepancies matching exists to catch.
How to test field-level sync in a demo
Bring your own data. Generic demo environments are configured to succeed.
- Send a real invoice with a real split. Four lines, four cost centers, one of them a project or job code. Watch whether the split happens in the platform or in a spreadsheet.
- Ask for a custom field. Add one during the demo and see whether it appears without a support ticket.
- Test the filtering. Select an entity and confirm the dimension list narrows. Select an account and confirm invalid dimension values disappear.
- Match against a partial receipt. Ask to match an invoice to a PO that was only partially received, at line level.
- Change master data mid-demo. Add a vendor or a dimension value in the ERP and ask how long until it appears. Then verify the answer rather than accepting it.
- Ask what is not supported. A vendor who names the boundary is easier to trust than one who never finds one. Record any behavior that is not documented as an open item to test in a sandbox.
Where Stampli fits
Stampli mirrors the ERP’s chart of accounts, entities, dimensions, vendors, approval hierarchies, and tax logic at field level, and syncs bi-directionally so the ERP stays the system of record. Coding happens against live ERP structure rather than a cached copy, which is what allows validation to run before posting rather than after. Stampli AI performs on average 87% of finance work across 2,700+ unique fields, with every suggestion reviewed by a person before it posts to the ERP. For a system-specific view of how that mapping works in practice, our breakdown of the field mapping behind the NetSuite integration walks through subsidiaries, segments, and line-level matching, and the full list of supported accounting systems and ERPs shows where each connection type applies.
Field-level sync is not a technical detail. It decides whether your team codes once or twice, and whether your close runs on schedule. Map your own required fields first, then make every vendor demonstrate against them. To see it against your real chart of accounts, request a demo and bring a messy invoice.
