Finance Index
How should corporate card transactions get into your ERP?
Reference guide to card transactions ERP integration, including card controls, policy design, employee spend workflows, receipt capture, and reconciliation.
Card transactions reach the ERP via bank/issuer feeds, file imports, or API integration from a card or spend platform. The reliability ranking is consistent: native API integration with coding context attached beats file imports, which beat manual entry. What matters as much as the pipe is what travels through it - a transaction that arrives without GL coding, dimensions, receipt, and approval history just relocates the work.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Corporate card policy | Card transactions reach the ERP via bank/issuer feeds, file imports, or API integration from a card or spend platform. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| ERP alignment | It depends on what you need downstream. | Keeps accounting records aligned with the ERP. |
| What should you test | Test with your real chart of accounts and dimensions, not the demo company: Does the integration carry department, project, job, location, and class - or just account and amount? | Keeps accounting records aligned with the ERP. |
| Card control | Feed format changes from the issuer, timezone/cutoff mismatches creating boundary duplicates, re-delivered files after outages, and card reissues breaking matching. | Keeps vendor records and payment decisions reliable. |
| How do we sync | Map at the card level - every card belongs to an entity, and its transactions post to that entity's books by default - with a reclass path for cross-entity purchases. | Keeps spend tied to policy, ownership, and review. |
Should card transactions post as journal entries, AP bills, or expense records?
It depends on what you need downstream. Journal entries are lightweight but lose vendor-level visibility - card spend disappears into expense accounts with no payee dimension. Posting with vendor attribution preserves vendor reporting and makes card and invoice spend comparable - which is exactly what you need to detect card drift. Expense-record posting suits T&E but fragments vendor analytics. The worst outcome is mixed conventions nobody documented.
What should you test about ERP integration before buying a card platform?
Test with your real chart of accounts and dimensions, not the demo company: Does the integration carry department, project, job, location, and class - or just account and amount? Do receipts and approval context attach to the posted entry or stay in the vendor's silo? Do GL and dimension changes in the ERP flow back automatically? How are refunds, FX, and partial disputes posted? What happens to in-flight transactions when a feed hiccups - retry, duplicate, or silent gap? And multi-entity: can one program post to multiple subsidiaries with the right treatment?
Our card feed keeps failing or duplicating - common causes and fixes?
Feed format changes from the issuer, timezone/cutoff mismatches creating boundary duplicates, re-delivered files after outages, and card reissues breaking matching. Fixes: idempotent imports keyed on transaction ID, a count-and-total control report per import, and an alert when a day arrives empty.
How do we sync card spend with entity and subsidiary structure?
Map at the card level - every card belongs to an entity, and its transactions post to that entity's books by default - with a reclass path for cross-entity purchases. Multi-entity programs that map at the statement level guarantee intercompany cleanup.
How does card spend hit job cost / project accounting modules?
Only if coding happens at or near the point of spend - a job-scoped card or job selection at receipt capture - and the integration writes to the project module, not just the GL. Card spend coded weeks later is invisible to committed-cost reporting exactly when project managers needed it.
What is level 2 / level 3 card data and does our integration use it?
Level 2 adds tax amount and customer code; level 3 adds line-item detail. Coverage depends on the merchant, so treat it as enrichment when present - many ERP integrations ignore it entirely, which is worth asking about rather than assuming.
Transactions sync but receipts and coding context don't - how do we keep the audit trail attached?
Require attachment and context sync as an integration capability, or at minimum a stable reference from the posted ERP entry back to the source record. An audit trail you have to reassemble across two systems will fail you in the exact moment you need it.
How do we handle FX on international card transactions?
Post in the settlement currency the issuer actually charges you (that's the cash impact), keep the original transaction currency and amount as reference fields, and book FX differences to a dedicated account rather than letting them blur into the expense line.
Stampli perspective
Stampli is ERP-native by design - it mirrors your chart of accounts, entities, and dimensions - and Stampli Card transactions inherit GL and project codes from the approved request, so card spend posts to the ERP coded the way the rest of your P2P spend is coded. Real-time transaction posting means the ERP's view of card spend doesn't lag the statement cycle.