Virtual Card ERP Integration: Real-Time Reconciliation Explained
Virtual card ERP integration means card transactions post into your accounting system carrying enough information to match themselves: merchant, amount, GL account, cost center, and a settlement reference. When that data flows continuously, reconciliation stops being a month-end project and becomes a background process.
The reason this matters is mundane. Most card programs grow faster than the process that accounts for them. A company adds virtual cards for supplier payments, extends them to employee purchasing, and eighteen months later the controller is still pulling a statement export into a spreadsheet and matching lines by hand. The program looks like a win on rebate capture and a loss on close time, which is a data problem rather than a card problem. Before deciding what your ERP needs from a card program, it helps to be precise about how virtual card payments work in B2B.
Key Takeaways
Integration is a data exchange, not a file download. The card platform sends transaction, vendor, and coding data to the ERP; the ERP sends back the account structure that makes coding possible.
A clean automatic match generally needs five things: merchant identity, amount, GL account, cost center or department, and a settlement reference that ties the transaction to the payment.
Batch statement exports are the reconciliation bottleneck. A monthly file means every exception surfaces at the worst possible time.
Only 32.6% of B2B invoices move straight through without manual intervention, according to Ardent Partners' 2024 ePayables research, so most finance teams are still touching transactions one at a time.
Real-time reconciliation shows up in close-cycle days and exception volume, not in headcount reduction.
What does it mean to integrate virtual cards with your ERP?
It means the card program and the ERP exchange structured data automatically, so a card transaction arrives in the general ledger already coded rather than waiting for someone to code it. The exchange runs both ways. Your card platform pushes transactions, merchant details, and card metadata into the ERP, and the ERP supplies the chart of accounts, cost centers, and vendor records the card platform uses to code correctly in the first place.
The volume behind this question keeps climbing. Juniper Research projected in 2024 that virtual card transaction value would rise from $3 trillion in 2024 to $11 trillion in 2028, making it the fastest-growing B2B payment method. US Visa and Mastercard purchase volume reached $9.367 trillion in 2024, up 6.3% year over year, according to The Nilson Report. A reconciliation process that worked at 200 card transactions a month behaves very differently at 4,000.
Which card data has to reach the ERP for a clean match?
Five data elements do most of the work. Everything else is useful for analysis but not required for the match itself.
Merchant identity: the normalized merchant name and category code, not the raw acquirer string that shows up as a jumble of abbreviations.
Amount and currency: the settled amount, plus the original currency if the purchase was cross-border.
GL account: either coded at issuance through the card's own rules or derived from merchant category and spend policy.
Cost center or department: carried on the card itself for employee cards, or attached to the purchase request for a single-use virtual card.
Settlement reference: the identifier that links authorization, settlement, and statement so the transaction reconciles to the payment rather than floating as an orphan.
The fifth one is where most integrations quietly fail. Plenty of platforms will push transaction data into an ERP. Fewer carry a reference that survives the trip from authorization through settlement, which is what lets the system prove that a posted expense and a cleared payment are the same event.
How is this different from exporting a card statement each month?
A statement export is a snapshot; an integration is a feed. With an export, transactions arrive in one batch after the cycle closes, already stripped of most context, and someone has to reattach the coding by hand. With an integration, each transaction posts as it settles, carrying its coding with it, and exceptions surface within a day or two of the purchase instead of three weeks later.
The shift toward electronic payment is what made the continuous model possible. Just 33% of US and Canadian B2B payments were made by check in 2022, down from 50% in 2013 and 81% in 2004, according to AFP's 2022 Digital Payments Survey. Electronic rails produce structured data as a byproduct; paper produces none, which is why check-heavy AP departments never had this option. The mechanics of matching a payment to its record are worth understanding on their own, and the fundamentals of payment reconciliation apply whether the instrument is a card, an ACH transfer, or a wire.
How does real-time reconciliation work step by step?
Real-time reconciliation follows the transaction from authorization to posted GL entry without a human touching it in between. The path has five stages, and the automation lives in stages three and four.
Most teams are nowhere near this today. Ardent Partners' 2024 ePayables research put average invoice processing time at 9.2 days against 3.1 days for the top-performing teams it surveyed. Card transactions are structurally easier to automate than invoices, since the merchant, amount, and timestamp arrive from the network rather than from a PDF, but many card programs still run through the same manual review loop.
Authorization. The cardholder or the virtual card number is used, and the network authorizes the transaction in under a second. At this point you have merchant, amount, and card identity.
Enrichment. The card platform normalizes the merchant name, attaches the merchant category code, and applies the card's coding rules to assign a GL account and cost center.
Transmission. The enriched transaction moves to the ERP through an API call or a scheduled connector, typically within hours rather than at cycle close.
Matching. The ERP matches the transaction against the expected purchase, the receipt, or the open PO, then posts it or routes it as an exception.
Settlement. The transaction settles, the settlement reference ties back to the posted entry, and the payment record closes.
What is the corporate credit card reconciliation process without automation?
Without automation, the corporate credit card reconciliation process is a monthly download-match-chase loop. Someone exports the statement, opens it beside the GL, matches transactions line by line, chases cardholders for missing receipts, recodes anything the cardholder assigned wrong, and books the journal entry once everything ties.
It breaks in predictable places. Receipts go missing and the chase eats days. Cardholders code to whatever account they used last time. Merchant names on the statement bear no resemblance to the vendor in the ERP, so the matcher guesses. A single disputed charge can hold a whole entity's reconciliation open. None of this is exotic, and anyone who has run corporate card expense reconciliation at scale can recite the list from memory.
Best practices for a virtual card program
Learn the internal strategies that make a virtual card program succeed — from program design to driving the vendor acceptance that determines how much of your AP spend earns rebates.
Download the guide
How does automated matching close the gap?
Automated matching works by making the coding decision at the moment of spend rather than after it. When a virtual card is issued for a specific purchase, the GL account, cost center, and expected amount can be attached to the card number itself. The card then can't be used for anything outside those parameters, and the transaction that comes back already knows where it belongs.
Employee cards work on rules instead of per-transaction issuance. Merchant category codes map to default accounts, cardholders map to cost centers, and spend policy handles the edge cases. The system routes anything that doesn't fit a rule to a human, which is the right use of a controller's time. That's the practical value of running card spend through a single platform for accounting and reconciliation: the coding logic and the transaction data live in the same place, so there's no export step where context gets lost.
Ask a vendor to show you the exception queue during a demo, not the happy path. Any platform can post a clean transaction. What tells you whether the integration is real is how a mismatched amount, a foreign-currency charge, or a partial refund actually behaves in the ERP.
Which ERPs support real-time card reconciliation?
Four ERPs cover most of the mid-market and enterprise finance teams asking this question: NetSuite, Sage Intacct, Microsoft Dynamics 365 Business Central, and Acumatica. All four support the connection patterns that real-time card posting requires, though the depth of the integration depends more on the card platform than on the ERP.
One division of labor holds across all of them. Your ERP owns the chart of accounts, the entity structure, and the posting rules, while the card platform owns transaction capture, enrichment, and control. Integration keeps those two views of the same spend in agreement without a person copying data between them.
How does it work with NetSuite, Sage Intacct, Dynamics 365, or Acumatica?
Each of the four handles the same core exchange with different plumbing. NetSuite tends to be API-first and handles multi-subsidiary posting natively, which matters when card spend crosses entities. Sage Intacct's dimensional structure maps well onto card-level cost center coding. Dynamics 365 Business Central works through its own connector framework. Acumatica's approach is API-driven with strong support for project and job-level coding, which shows up in construction and services firms.
The AP-side integration patterns for each are documented in more depth in the guides to NetSuite AP automation, Sage Intacct AP automation, Dynamics 365 Business Central AP automation, and Acumatica AP automation. The card side uses the same connection layer, so if the AP integration works, the card integration usually does too.
What if you're mid-migration between ERPs?
Mid-migration is the most common reason teams delay a card integration, and usually the wrong reason to delay it. The card platform holds transaction history independently of the ERP, so a migration doesn't lose card data. What you do have to plan for is the coding map, since GL account structures rarely survive a migration unchanged.
Run both connections in parallel for a cycle if the platform supports it. Post to the legacy ERP as the system of record while validating that the new one receives and codes the same transactions correctly, then cut over once a full cycle ties. It's an unglamorous approach and it adds a month, but it beats discovering a coding gap after the legacy system is decommissioned. The broader pattern of how ERPs and invoice-automation providers handle digitization is worth reading before scoping a migration.
What does real-time reconciliation change for close and controls?
It changes when work happens more than how much work happens. Exceptions that used to pile up for a month-end sprint get resolved as they occur, which flattens the workload and shortens the close. Controls tighten as a side effect, because a transaction that violates policy is visible within a day instead of after the money is gone.
The economics are easier to see on the AP side, where the benchmarks are better established. Ardent Partners' 2024 research found top-performing teams process an invoice for $2.78 against a $9.40 average. Card transactions don't have a directly comparable per-unit figure, but the same driver applies: the cost is in the touches, and each touch you remove takes its cost with it.
The data to do this in real time already exists. Mastercard recorded 159.4 billion switched transactions in full-year 2024, every one of them authorized in roughly a second. The delay in most finance teams' reconciliation isn't in the payment network. It sits in the gap between when the network knows about a transaction and when the ledger does.
How much manual work does it remove?
Less than most vendor decks imply, and in a different place than you'd expect. Automation removes the matching and coding work almost entirely for in-policy transactions, which is the bulk of volume. It does not remove receipt chasing, dispute handling, or the judgment calls on ambiguous spend, and anyone who tells you otherwise hasn't run the process.
What actually changes for a finance team:
Coding and matching for routine transactions drop close to zero manual effort.
Exception handling stays, but the queue is smaller and arrives continuously instead of in a month-end wave.
Receipt collection improves when the platform prompts at the time of purchase, though it never gets all the way there.
Month-end journal entry preparation shrinks because most entries are already posted.
I'd push back on any ROI model that assumes headcount reduction here. The teams that get the most out of card integration usually keep the same people and redeploy them onto vendor negotiation, spend analysis, and control work that was previously impossible to staff.
Reconcile card spend in the ERP you already run
Corpay is Mastercard's #1 commercial B2B issuer, and the platform connects to more than 180 ERP systems through API, SFTP, or file-based connections. That combination is the point: your card program and your accounting system stay in agreement without a monthly export, and card transactions post with the merchant, coding, and settlement data your ERP needs to match them automatically.
Corpay's virtual cards let you set the GL account, amount, and merchant restrictions at issuance, so the coding decision happens before the spend rather than after it. Corporate cards apply the same control model to employee and departmental spend with rules instead of per-transaction issuance. Both post through the same ERP integration layer that handles the AP side.
If you're evaluating how card spend would post into your specific ERP and entity structure, ask for a walkthrough against your chart of accounts rather than a demo environment. The criteria that separate providers on this are covered in the guide to choosing a virtual card provider.
Frequently Asked Questions
How do you automate credit card reconciliation?
You automate credit card reconciliation by connecting the card platform to the ERP so transactions post with coding attached, then setting rules that assign GL accounts and cost centers based on merchant category, cardholder, or the card's own issuance parameters. Anything that doesn't match a rule routes to a person as an exception.
What is the corporate credit card reconciliation process?
The corporate credit card reconciliation process matches every card transaction to a supporting record, assigns it to the correct GL account and cost center, and confirms that posted expenses tie to the cleared payment. Manually it runs monthly from a statement export. With an integration it runs continuously as transactions settle.
Does virtual card reconciliation happen in real time?
Close to it, with a caveat. Transaction data can reach the ERP within hours of authorization, but final settlement takes one to three business days depending on the merchant and network. Most platforms post the authorization immediately and update the record at settlement, so the ledger reflects spend the same day and the payment reference completes shortly after.
What card data does the ERP need to auto-match a transaction?
At minimum it needs a normalized merchant name and the settled amount. Beyond that, a GL account and a cost center let the system code the entry, and a settlement reference links the authorization to the payment. Missing the settlement reference is the most common cause of transactions that post correctly but never fully reconcile.
Is credit card reconciliation software different from an ERP integration?
They solve overlapping problems from different directions. Standalone reconciliation software sits between the card statement and the ledger and automates the matching. A card platform with a native ERP integration removes the intermediate step by coding transactions at the source, which means fewer systems to maintain and no separate matching database to keep in sync.
Switch to Corpay
Discover how making the move to Corpay streamlines payments and strengthens your business.
Talk to an ExpertSmarter payments. Stronger growth. Keep business moving.
Corpay powers payments for 800,000+ businesses worldwide. Let’s build what’s next for yours.