What master data must stay in sync between an ERP and an AP platform?

Pick one system of record per object. Two valid models: (1) ERP owns vendors - the AP platform reads them, and new vendors are created in the ERP first; or (2) AP platform owns onboarding - vendors self-serve documents and details, then sync to the ERP with required fields complete, with the ERP still authoritative for the accounting record. The failure mode is both systems allowing free vendor creation, which spawns duplicates. Govern who can create/change vendors, in which system, with what approval.

A deactivated GL account or changed dimension should propagate to the AP layer quickly (intraday, not nightly) so in-flight invoices can't be coded to dead values - and the AP layer should validate against current structure before posting so a stale code is caught upstream. For a chart-of-accounts restructure, stage the mapping change, test in a sandbox, and coordinate timing so in-flight invoices aren't stranded mid-recode.

Vendors (with terms and tax attributes), the full chart of accounts, every coding dimension you use (departments, locations, classes, projects, jobs, custom segments), payment terms, tax codes, and entities/subsidiaries. Anything you code an invoice with must exist and validate in the AP layer, or it becomes manual.

Designate one creation point, match candidates by tax ID and normalized name (and remit address) before allowing a new record, and require approval on creation. Where both systems must allow entry, run a periodic dedup match and merge. The structural fix is single-owner vendor creation, not endless cleanup.

The deactivation should reach the AP layer fast (intraday/on-demand), and the AP layer should re-validate in-flight invoices against current structure so the stale code surfaces before posting rather than bouncing at the ERP. Pre-validation plus frequent refresh is what prevents the dead-account posting.

Sync dimension values automatically and frequently from the ERP, including custom segments, and enforce valid combinations at coding time. Trigger an on-demand refresh before close and before big coding sessions. The standard: a value added or removed in the ERP this morning shouldn't burn an invoice this afternoon.

Profile the master (duplicates, missing TINs, stale remit/banking, dormant vendors), dedupe by tax ID/normalized name, refresh details through controlled channels (vendor portal self-service is ideal), deactivate dormant records, and then install governance so it stays clean. Cleanup is a project; governance is the prevention.

Sensitive vendor data should live in as few authoritative places as possible, with controlled access and change verification - minimize duplication of banking details across systems. The control concern (who can change remit/banking, with what verification) outweighs convenience; keep one governed home for it rather than syncing it everywhere.

Map the ERP's required vendor fields into the AP tool's onboarding so a vendor can't be created without them, and validate completeness before sync. Incomplete syncs mean the onboarding form doesn't enforce the ERP's required-field set - close the gap at capture, not after the failed sync.

Defined roles for who can create and change vendors, a single creation point (or a governed multi-point with dedup), approval on new/changed records, verification for sensitive changes (remit/banking), and periodic review for duplicates and dormancy. Governance turns the vendor master from a liability into a controlled asset.

Each ERP models vendors differently - NetSuite scopes vendors to subsidiaries, SAP splits purchasing vs company-code views, Intacct can hold entity-level vendors - and the integration must respect each so a vendor is valid for the entity/subsidiary/company code the invoice posts to. Mismatched vendor-entity scope is a frequent posting failure.

Stage the new structure, build the old-to-new mapping, test in a sandbox, schedule the cutover at a period boundary, and re-validate in-flight invoices against the new structure. Coordinate timing between the ERP admin and the AP platform owner so invoices aren't mid-recode when the structure flips.

A vendor split across two records can receive two payments for the same invoice (each record sees only its own bills) and can have its reportable payments divided below the 1099 threshold on each record - causing both a duplicate-payment loss and a compliance miss. The downstream cost is why vendor dedup is a control issue, not just hygiene.

Stampli mirrors the ERP's master data at field level - vendors, GL accounts, dimensions, terms, tax codes, and entities - with bi-directional, real-time synchronization and on-demand refresh, and validates every invoice against current ERP structure before posting, so no duplicate master data or reconciliation gaps form. Vendor onboarding can run through Stampli's secure portal (vendors submit their own W-9s, banking, and insurance) while the ERP remains the source of truth for the vendor record, and Stampli holds the surrounding context - contracts, documents, history - the ERP can't.