When Finance Work Becomes Integration Work

The question is why a weekly operational meeting can matter as much as a formal steering committee. On the surface, the topics are ordinary: ERP configuration, intercompany billing, FP&A tooling, hours tracking, and merger migration. But what is at stake is not the meeting itself. It is whether finance, operations, and technology are building one system or several disconnected ones.

From first principles, the work is about trust. Can the company trust that time is captured in the right place, costs are allocated to the right entity, forecasts are built from current data, and a merger is absorbed without creating a parallel operating model? Each item sounds administrative until it becomes a control issue, a reporting delay, or a decision made from stale information.

This is why project syncs deserve more attention than they usually receive. They are where abstract strategy meets configuration fields, process owners, dependencies, and unresolved exceptions. The quality of the system is shaped in these details.

The ERP Is the Operating Frame

An ERP platform is often described as a system of record. That is true, but incomplete. In an integration or growth environment, the ERP becomes the operating frame for how the business defines work, revenue, cost, ownership, and accountability.

That is why configuration choices should not be treated as technical preferences. They determine how work flows through the organization.

Key questions include:

Which entities are transacting with each other?
Which costs are billable, allocable, or absorbed?
Which project codes carry financial meaning?
Which approval paths are required before billing occurs?
Which reports must reconcile to the general ledger?

A weekly meeting that reviews ERP configuration is really reviewing the shape of the business. If the system cannot represent the operating model, people will create workarounds. Those workarounds may solve the immediate problem, but they usually create later reconciliation work.

The goal is not perfect configuration on the first attempt. The goal is disciplined configuration: clear decisions, known owners, documented assumptions, and a visible path for exceptions.

Intercompany Billing Is a Control System

Intercompany billing is easy to underestimate because it happens inside the corporate group. No external customer is waiting for an invoice. No vendor is threatening to stop service. But internal billing affects margin, tax, entity performance, transfer pricing, and management reporting.

In a multi-entity environment, intercompany billing is not just accounting cleanup. It is a control system.

A practical intercompany model needs three things:

A clear policy for what gets charged between entities
A repeatable process for capturing and approving those charges
A reconciled system trail from source activity to invoice to ledger

The hardest part is often not the invoice. It is the source data. If hours, projects, departments, or service categories are inconsistent, the billing process becomes an interpretation exercise. Finance then spends time reconstructing intent after the work has already happened.

That is a fragile model. A better model moves clarity upstream.

For example, if employees are entering hours against projects that serve multiple entities, the time-entry structure must support that allocation. If shared services are being charged out monthly, the cost pools and drivers need to be agreed before the month closes. If one entity is providing implementation support to another, the project setup should make that relationship visible.

The meeting is where these linkages get tested. Does the ERP have the right fields? Are the right people using them? Can billing be generated without offline calculation? If not, what is the temporary bridge, and when does it retire?

FP&A Tooling Depends on Process Discipline

FP&A tools often promise better forecasting, faster reporting, and cleaner scenario planning. Those outcomes are possible, but only if the upstream process is stable enough to support them.

A planning tool cannot compensate for unclear ownership. It cannot decide which version of actuals is authoritative. It cannot repair project codes that were created inconsistently. It can expose these issues faster, which is useful, but exposure is not the same as resolution.

The integration between ERP and FP&A tooling should be designed around decision needs, not around data movement alone.

The basic design questions are:

What decisions will leaders make from the forecast?
Which dimensions are required for those decisions?
How frequently does the data need to refresh?
Which adjustments belong in the planning tool versus the ERP?
Who owns variance explanations?

If the FP&A tool becomes a second ledger, the organization has a problem. The planning environment should support interpretation, forecasting, and scenarios. It should not become the place where unresolved operational data is corrected indefinitely.

This is where finance teams need to be firm. Some issues should be solved in the planning layer. Many should be solved in the operating layer. The distinction matters because every manual planning adjustment creates a maintenance burden.

Hours Tracking Is More Than Utilization

Hours tracking is often framed as a utilization metric. That can be useful, especially in services or project-based environments. But in an integrated finance system, hours are also a cost attribution mechanism.

They answer basic questions:

Where was effort spent?
Which entity benefited?
Which project consumed capacity?
Which costs should be capitalized, billed, allocated, or expensed?
Which activities are recurring versus transitional?

In a merger or ERP migration, hours tracking has another role: it reveals the true cost of change. Integration work consumes internal capacity. If that work is invisible, leadership may underestimate the effort required and overcommit the organization.

A good hours process should be simple enough for teams to follow and structured enough for finance to use. Too much detail leads to poor compliance. Too little detail creates unusable reporting.

The practical middle ground is to define a limited set of categories that map to real decisions. For example:

Run-the-business work
ERP configuration and testing
Intercompany billing support
Merger integration activities
FP&A implementation support
Exception resolution and cleanup

This structure gives leadership a view of where capacity is going without turning time entry into a burden. It also creates a basis for project costing, capitalization analysis, and post-integration review.

Merger Migration Requires a Single Source of Operational Truth

A company merger migration scoped through an ERP platform is not only a data project. It is a business model translation exercise.

The acquired or merging company may have different charts of accounts, customer structures, billing rules, project conventions, approval workflows, and reporting habits. The task is not simply to move data into the platform. The task is to decide how the combined company will operate after migration.

That requires a few disciplined decisions:

What legacy structures will be preserved, and why?
What will be standardized at migration?
What will be temporarily bridged?
Which reports must remain comparable before and after cutover?
Which controls must be tested before go-live?

There is always pressure to defer decisions. The phrase often used is that the business will harmonize later. Sometimes that is appropriate. But later harmonization has a cost. It can mean duplicate processes, custom reporting, manual reconciliations, and confusion over ownership.

The better approach is selective standardization. Not everything needs to be rebuilt on day one. But the organization should be explicit about what is standard, what is transitional, and what is intentionally local.

The Weekly Meeting as a Decision System

The value of a weekly sync is not in status reporting. Status is necessary, but insufficient. The meeting should function as a decision system.

That means every agenda item should move toward one of five outcomes:

A decision is made
An owner is assigned
A dependency is identified
A risk is escalated
A date is confirmed

If a topic does not move toward one of these outcomes, it may not belong in the meeting.

A strong operating cadence also separates different types of work. Configuration issues should not be mixed with policy decisions without naming the difference. Data cleanup should not be treated the same as process design. Testing defects should not obscure unresolved ownership questions.

One useful structure is to maintain a simple decision log:

Decision required
Options considered
Recommendation
Decision owner
Due date
Downstream impact

This is especially important when finance, operations, IT, and integration teams are all involved. Without a decision log, the same topics resurface. People remember the conversation differently. Work proceeds based on assumptions rather than agreement.

Where the Risk Usually Lives

The largest risk in this kind of work is rarely one dramatic failure. It is accumulated ambiguity.

A field is configured without a clear owner. A billing rule is agreed verbally but not documented. A project code is created for temporary use and then becomes permanent. A planning adjustment is made once and then repeated every month. A migration exception is accepted without a retirement date.

Each item is small. Together, they define the system.

Executives should pay attention to these signals:

Finance relies on spreadsheets to complete core billing steps
ERP and FP&A numbers do not reconcile without manual explanation
Integration hours are not visible in reporting
Intercompany balances require late-cycle cleanup
Teams cannot explain which process is temporary and which is permanent
Data migration decisions are being made without process owners present