What happens when an ERP integration breaks, and who is responsible?

Connection-health monitoring with alerting: last-successful-sync timestamps per integration, export-queue depth and age, failed-records by error type, and credential/token expiry warnings - with thresholds that page a human rather than waiting for someone to notice. A silent failure (sync died days ago, nobody knew) is the canonical close-wrecker, and it's entirely preventable with active monitoring and an owner who looks at it.

Assign it before go-live across three lanes: the AP vendor (for a native connector they maintain), the ERP publisher (for ERP-side changes), and your IT or implementation partner (for custom builds or environment issues). The structure that prevents the blame loop is a maintained native connector with the vendor contractually owning its function through ERP updates - plus support contracts that don't let the AP vendor and ERP partner each say "it's the other one." Settle ownership and SLAs in writing.

Triage: confirm the symptom (where syncing stopped), check connection health and credentials, identify whether an ERP update or a mapping change preceded it, and check the error type on stuck records. Call first whoever owns the maintained connector - typically the AP vendor for a native integration - and escalate to the ERP publisher if it's an ERP-side change.

Define the three lanes (vendor, ERP publisher, IT/partner) and write into contracts who owns connector function through ERP updates, with response SLAs. The goal is that any break has a pre-assigned first responder, so the first hour goes to fixing rather than to arguing about whose problem it is.

Active connection-health monitoring with alerts: per-integration last-sync timestamps, queue depth/age, failed-record counts, and credential-expiry warnings, with thresholds that notify a named owner. The fix for silent failure is that something watches the integration continuously and tells a human when it stops.

A sandbox-first policy (test the connector against ERP updates before they hit production), a habit of reading both the ERP's and the AP vendor's release notes, coordination before structural changes (new GL segments, renamed dimensions), and a rollback plan. Most breakages are preventable updates applied without testing.

Use service accounts with monitored expiry, alert before tokens/credentials lapse, rotate on a schedule, and avoid shared personal credentials that break when someone leaves. Expired-credential silent death is common and entirely preventable with expiry monitoring and proactive rotation.

For a vendor-maintained native connector, low - mostly monitoring and occasional coordination around ERP updates. For a custom-built integration, materially more - engineering hours to keep pace with both endpoints' changes, plus the key-person risk. Budget the difference honestly when choosing custom vs native.

Stabilize first (get it monitored and limp it through close if needed), then reverse-engineer and document the field mappings, sync schedule, and error handling - and seriously evaluate replacing the orphaned custom build with a vendor-maintained native connector. Orphaned undocumented integrations are a standing risk; the durable fix is removing the bespoke dependency.

Native vendor-maintained connectors are generally more reliable long term: the vendor amortizes maintenance across many customers, tracks ERP updates proactively, and owns the breakage. Custom builds offer maximum fit but put all maintenance and key-person risk on you. For commodity AP-to-ERP sync, native wins on reliability and total cost.

Document the field mappings (each direction), the sync schedule and triggers, the auth method and credential owners, the error playbook (common failures and fixes), and the escalation contacts. Keep it with the close runbook. The test: a new hire could triage a break from the doc without calling the person who left.

Make one party contractually own the connector's function end to end (usually the AP vendor for its native integration), define joint-escalation terms, and require named SLAs so neither can deflect. Where you must keep multiple parties, a single accountable "integration owner" on your side coordinates them - but the cleanest fix is a maintained native connector with clear vendor ownership.

Stampli maintains its ERP connectors and monitors connection health, validating invoices against current ERP structure before export so most would-be sync failures are caught upstream - and when a record-level error does occur, it surfaces on the specific invoice with enough context for AP to fix and retry without an IT ticket, while connection-level issues (expired credentials, bridge offline) trigger alerts rather than silence. Because Stampli owns the maintained connector, the "who's responsible" question has a clear default answer rather than a vendor-vs-partner standoff.