How Expense Management Software Integrates With Your ERP

Expense management software connects to an ERP in one of four ways: a prebuilt native connector, a custom API integration, a scheduled flat-file export, or manual re-entry. Which one a finance team ends up with depends less on the expense vendor's integration list and more on how heavily customized the ERP's chart of accounts and dimension structure already is.

Integration failures almost never look like a broken connection. They could look like a month-end close where 40 expense lines posted to the wrong cost center, or a batch that rejected because three employees exist in the expense tool but not as vendor records in the ERP. This is why it's important to know the different ways your ERP can connect to an expense software.

The four integration patterns

Most mid-market finance teams assume they are buying pattern one and discover during onboarding that their configuration requires pattern two or three.

What actually has to map

Six things have to line up between an expense platform and an ERP before a single report can post cleanly.

• GL accounts: Every expense category in the expense tool needs a corresponding GL account or accounting code in the ERP. Categories that exist on one side only will either fail on import or land silently in a suspense account.
• Cost centers and dimensions: ERPs model this differently. NetSuite uses classifications like class, department, and location. Sage Intacct uses a configurable dimension model. QuickBooks Online uses classes and locations. An expense platform has to support however many dimensions you tag against, and support them as required fields at entry rather than as optional metadata a submitter can skip.
• Employee and vendor records: The ERP needs to recognize the person being reimbursed. Whether an employee posts as an employee record or a vendor record changes what transaction type the expense report becomes on arrival.
• Tax codes: GST, HST, PST, and VAT breakouts need to survive the trip, ideally per line rather than per report. Cross-border teams should confirm this explicitly.
• Currency and rates: One system owns the exchange rate, as of a specific date. Mismatched rate sources produce small, permanent, irritating variances.
• Approval status: The integration needs a clear trigger. Most platforms post on final approval, which means the approval hierarchy in the expense tool has to mirror your actual delegation of authority rather than a simplified version of it.

The first four items are where implementations stall. Custom fields on the ERP side are the single most common cause, because a connector cannot map fields it does not know exist.

Expense report or vendor bill: the decision most teams do not know they are making

Approved expenses can post to an ERP as either an expense report transaction or a vendor bill, and the choice has downstream consequences for AP workflow, payment runs, and reporting.

NetSuite makes this explicit. In Oracle's integration documentation for expense report export workflows, approved expense reports export to NetSuite as expense report transaction records when the associated employee was imported as an employee record, or as vendor bill transaction records when the employee was imported as a vendor. The same documentation notes a limitation worth knowing before you architect this: when exporting as expense reports rather than vendor bills under the SuiteTax engine, tax details have to be entered manually in NetSuite.

That is the level of detail to press a vendor on. "Do you integrate with NetSuite" has a yes answer from nearly everyone. "What transaction type do approved reports create, and how are tax breakouts handled on that record type" separates vendors who have done real implementations from vendors with a marketplace listing.

Notes by ERP

NetSuite: Integrations typically arrive as SuiteApps and authenticate directly. Dimension mapping runs through classifications, and multi-subsidiary environments need entity-level mapping confirmed up front. Tax handling differs between legacy tax and SuiteTax, so ask which your instance runs.

Sage Intacct: The configurable dimension model is both the strength and the complication. Teams that have built out custom dimensions or custom fields on the bill record should expect scoped development rather than a plug-in connector, and should budget onboarding time accordingly.

Sage 300 and other on-premise Sage products: Scheduled flat-file import is common and entirely workable. It is not a downgrade, but it does mean someone owns a recurring import step, so agree on who and how often before go-live.

Microsoft Dynamics 365 Business Central: Cloud instances generally support API-based integration. On-premise and older Dynamics NAV or GP environments usually land on flat-file.

QuickBooks Online: The simplest chart structure of the group and usually the fastest integration, with classes and locations doing the work that dimensions do elsewhere. The constraint is depth, not connectivity.

Acumatica: API-based integration is available, though the connector ecosystem for expense tools is thinner than NetSuite's, so verify the specific pairing rather than assuming it.

Homegrown and industry-specific systems: Dealership, construction, and field-service teams frequently run proprietary systems with no connector ecosystem at all. Flat-file export against an agreed schema is almost always the answer, and it works well as long as both sides commit to a fixed file format.

Questions to ask before you sign

Bring these to the vendor demo, and ideally to a technical call rather than a sales call.

1. Is the integration for our exact ERP version a prebuilt connector, or scoped development? Ask for the distinction in writing.
2. How many dimensions or segments can post per expense line, and are they enforceable as required at submission?
3. What transaction type do approved reports create in the ERP?
4. How are tax codes handled per line, and does that change with our tax engine?
5. If we have custom fields on the target record, what does supporting them cost and how long does it take?
6. Is the sync one-way or bidirectional, and what happens to a report that fails on import? Who sees the error?
7. Who maintains the integration after go-live, and what happens when the ERP's API changes?

Comparing platforms on integration depth rather than integration count is the whole exercise here.

FAQs