Scoping Intercompany AR/AP Automation

The question is why an operational scoping call deserves careful attention. It is not just a meeting to collect requirements. It is where a finance problem becomes a system design decision, and where small assumptions can either reduce work for years or preserve the same manual burden in a new form.

What’s at stake in intercompany AR/AP automation is the integrity of the close. Intercompany activity touches legal entities, revenue and expense recognition, allocations, approvals, tax treatment, currency, audit evidence, and cash visibility. If the automation is scoped too narrowly, the team may only move spreadsheet work into the ERP. If it is scoped too broadly, the build can become expensive before the operating model is clear.

From first principles, every intercompany transaction needs a source, a counterparty, a trigger, posting logic, approval evidence, and a reconciliation path. The scoping call should test each of these items before anyone decides whether the answer is ERP customization, workflow, managed services process design, or a combination of all three.

Start with the transaction grammar

The first useful move is to describe the transaction in plain language. Who provides the service? Who receives it? What creates the obligation? What document should exist on each side? What should happen if one side disagrees?

For an AMC-style intercompany billing process, the activity may include management fees, shared services charges, technology allocations, payroll support, or other costs moved between related entities. Each category may look similar at the invoice level, but the rules underneath can differ.

A practical scoping call should map the grammar of each charge type:

Provider entity: the company that records AR or revenue recovery
Recipient entity: the company that records AP or expense
Basis of charge: fixed fee, headcount, revenue percentage, usage, direct cost, or allocation key
Frequency: monthly, quarterly, annual, or event-based
Evidence: contract, rate table, allocation workbook, service log, or approval record
ERP objects: customer, vendor, item, GL account, department, project, tax code, currency, and intercompany relationship
Close behavior: accrual, reversal, invoice posting, settlement, and reconciliation

This language matters because automation depends on stable definitions. If the team cannot state the rule, the system cannot apply it consistently.

ERP customization versus process discipline

One of the central design decisions is whether the ERP should be customized. The right answer depends less on technical possibility and more on operational maturity.

Customization is useful when rules are repeatable, data sources are reliable, and exception paths are known. It is risky when it compensates for unclear ownership, changing allocation methods, or missing master data. In those cases, the build may become a collection of hard-coded exceptions that finance cannot maintain.

A better framing is to separate the work into four layers:

Standard ERP configuration: entities, intercompany relationships, approval workflows, invoice templates, accounts, dimensions, and posting rules
Light customization: scripts, saved searches, custom fields, automated document creation, and validation logic
External process support: intake forms, allocation tables, workflow tools, or data staging before ERP posting
Managed services procedures: billing calendar, review steps, exception handling, and close checklists

The scoping call should not begin with the question of what can be built. It should begin with what should be controlled. For example, if managed services billing is currently prepared in a workbook, the issue may not be the workbook itself. The issue may be that the workbook contains the billing logic, approval evidence, source data, and exception notes in one fragile place.

In that case, the design goal is not simply to replace the spreadsheet. The goal is to move the durable rules into governed tables, move approvals into a visible workflow, and move postings into the ERP with enough traceability for close and audit.

Treat managed services billing as an operating model

Managed services billing often looks like a back-office task, but it functions as an operating model. It defines how one entity charges another for work performed on its behalf. That means it needs clear policy, not only automation.

The core artifacts are simple:

Service catalog: what services are billable and under which agreements
Rate and allocation table: how charges are calculated
Billing calendar: when charges are prepared, reviewed, posted, and settled
Approval matrix: who can approve rates, allocations, exceptions, and final invoices
Evidence package: what support is retained for each billing cycle
Exception log: what changed, why it changed, and who approved it

Once these artifacts exist, automation has something to follow. Without them, the system may generate invoices faster, but the team will still rely on manual review to determine whether the invoices are right.

Design for mirrored outcomes

Intercompany automation should create mirrored outcomes. The provider should not have a clean AR invoice while the recipient has no corresponding AP record, no accrual, or a mismatched expense classification.

A strong design uses a common transaction identifier that links both sides. One source event can generate the provider-side AR and either the recipient-side AP, accrual, or draft invoice for review. The system should also maintain shared status: drafted, reviewed, approved, posted, rejected, reversed, or settled.

This is where scoping becomes specific. The team needs to decide:

Should the recipient entity approve before the provider invoice posts?
Should AP be created automatically, or only after review?
What tolerance is allowed between AR and AP?
What happens when periods are closed on one side but open on the other?
Who owns corrections and reversals?
Should settlement be tracked inside the ERP or handled separately?

These questions are not edge cases. They are the control structure of the process.

The questions that change the build

A good scoping call should surface the answers that materially change cost, timeline, and design. The most important questions are usually operational, not technical.

Key questions include:

How many legal entities participate today, and how many may be added later?
Are entities on the same ERP instance or different systems?
Are customer and vendor records already linked for each intercompany pair?
How many billing categories exist, and which are recurring?
Are charges calculated from ERP data, external data, or manual inputs?
Do allocations change monthly, or are they fixed for a period?
Are there tax, withholding, or regulatory considerations by entity or jurisdiction?
Are multiple currencies involved?
Do invoices require attachments or supporting schedules?
What approvals are required before posting?
What reports are needed for close, audit, and management review?
What volume of monthly transactions is expected?
What errors occur most often today?

The answers should produce a scope boundary. Some items belong in the first build. Others belong in a later phase. Some should not be automated until the policy is stable.

Prototype the thin slice first

The safest next step is a thin-slice prototype. Pick two entities, one recurring service category, one allocation method, and one monthly billing cycle. Build enough to prove the operating pattern without trying to cover every exception.

The prototype should show:

Source data intake or entry
Calculation of the charge
Creation of the provider-side invoice or journal
Creation of the recipient-side AP, accrual, or draft record
Approval routing
Exception handling
Reversal or correction path
Reconciliation report linking both sides

This gives finance, operations, and technology a shared object to evaluate. It also reveals whether the ERP customization is doing the right work or whether more process definition is needed before scaling.

Define ownership after launch

Automation does not remove ownership. It changes where ownership sits.

After launch, the process needs named owners for rule maintenance, master data, exception review, close reconciliation, and change control. If allocation keys change, someone must approve and update them. If a new entity is created, someone must confirm customer and vendor relationships, posting rules, and approval paths. If a transaction fails, someone must decide whether the issue is data, configuration, policy, or timing.

Useful metrics are modest but important:

Percentage of intercompany charges created automatically
Number of exceptions per cycle
Time from billing preparation to posting
AR/AP mismatch count
Manual journal entries required after automation
Close days affected by intercompany activity
Aging of unresolved intercompany balances

These measures help the team see whether the system is reducing work or only moving it.

Ultimately, the value of an intercompany AR/AP automation project is not measured by how much customization is delivered. It is measured by whether the organization can generate, approve, post, and reconcile related-party activity with less ambiguity and fewer manual interventions.

What this means for a scoping call is simple: slow down at the beginning. Define the transaction grammar, confirm the managed services billing model, separate policy from system behavior, and design for mirrored outcomes. The technical build will be clearer when the operating model is clear.

The takeaway is that intercompany automation is a finance control project as much as an ERP project. The best scope is not the largest one. It is the one that makes the next close more reliable, gives the team better evidence, and creates a foundation that can be extended without rewriting the process.