Configure tax calculation in parallel with your enterprise resource planning (ERP) project's data-mapping and design phase, ideally before go-live. Tax requirements touch the same ground the ERP project is already covering. Building tax logic in during that design work reduces reworking it once the system is already live.
This page is for finance, information technology (IT) systems, and revenue operations (RevOps) leaders mid-way through, or about to start, an ERP implementation or migration, on NetSuite, Business Central, another Dynamics 365 product, Epicor, or a comparable system, who need to decide when tax calculation gets configured relative to that project.
An ERP or billing-system change is the single most common reason companies start evaluating tax automation with CereTax. During recent conversations (as of August 2026) with our current customers and prospects, an ERP or billing-system change under way was the reason cited most often, more than four times as often as the next most common reason. That figure describes a snapshot, not a permanent rate. It is still, by a wide margin, the largest single reason this question comes up at all.
In that same snapshot, the most common hesitation concerned the switch itself: whether a tax engine would connect to the systems the team runs, and whether the team could manage two changes at once. Inside that broader hesitation, deferring tax configuration until after the ERP project finished up was a documented pattern, cited by name in multiple conversations, though our own data counts it only as part of that broader hesitation. The pattern makes sense on its face: a team already absorbing one major system change looks for ways to limit how much changes at once, and pushing tax configuration to "later" looks like it does that. Deferring usually moves the same work later and adds to it; the sections below explain why.
When tax requirements are part of an ERP project from the start, they become part of the design. Early involvement lets a team build tax logic into process design, data structures, and integrations as those get built the first time. Innovate Tax, an indirect-tax technology consultancy, makes this case plainly: treating tax as something that can be "fixed later" is one of the more common misconceptions in ERP projects.
At a planning level, this means folding tax into the same data-mapping and process-design conversations already happening for the rest of the ERP project:
Treating tax configuration as something to add once the ERP is live is the more expensive path, because remediation after the fact commonly means reworking decisions that already shipped. Baker Tilly, a national accounting and advisory firm, recommends including tax considerations during the initial implementation phase specifically to avoid this. Post-implementation enhancements are, in the firm's own words, "costly and burdensome," and the oversight can mean significant data gathering and rework once the system is already in production.
Innovate Tax describes the same mechanism from the ERP-migration side: post-implementation tax remediation often means reworking core data structures, reconfiguring integrations, and in some cases reversing design decisions that the wider system now depends on. That adds project spend and unplanned delay to what looked, at the planning stage, like a simple later addition. Neither firm puts a number on that cost. The case is about what gets reworked.
If tax configuration was deferred and the ERP is already live, the same logic above still applies: the data structures, integrations, and process decisions made without tax in mind are the starting point for any remediation, and the more the rest of the system comes to depend on them, the more there is to unwind. Raise it with your ERP implementation team as soon as the decision to defer becomes a decision to configure.
If timeline is the reason tax configuration keeps getting pushed to "after," it is worth checking how much time configuring it actually takes. For CereTax customers on Business Central, most finance teams are live in a couple of weeks. Rob Waybright, VP of Technology, described his company's experience of that difference: "When we switched over to CereTax we were able to implement all our customers within 3 months whereas it took 18 months with Avalara."
These are our own setup-duration figures, not sequencing advice: they describe how long we take to configure, not when in an ERP project that work should start. Configuring the CereTax engine is a short piece of work next to an ERP project. That says nothing about how long any other tax engine takes, and the case for starting during ERP design rests on the sources above.
If tax configuration is still an open item on your ERP project plan, talk to us about your timeline, whether the project is still in design or already live.
