Scoping Intercompany Automation in the ERP

The question is why intercompany accounting still consumes so much manual effort after an ERP has been implemented. The answer is usually not that the system cannot do the work. It is that the relationship between entities, customers, vendors, approvals, and payments has not been translated into a controlled workflow.

What’s at stake is not only time. Manual intercompany AR and AP creates reconciliation drift. One side books an invoice. The other side waits for a bill. A field is copied incorrectly. A subsidiary is missed. A payment is applied to the wrong open item. Each small gap becomes month-end work.

From first principles, the problem is simple: when one entity creates its side of an intercompany transaction, the ERP should be able to create the opposing side with the right entity, subsidiary, and accounting context. The work is in defining when that should happen, what should be copied, what should be flipped, and how users should recover when something is wrong.

The Core Workflow: Create the Opposing Transaction

The main item scoped was an intercompany AR/AP automation. If a user creates an invoice on one subsidiary, the system should automatically generate the related vendor bill on the opposing subsidiary. If a user creates a vendor bill first, the system should generate the related invoice.

The important mechanic is the flip:

• Customer becomes vendor.
• Vendor becomes customer.
• Source subsidiary becomes target subsidiary.
• Target subsidiary becomes source subsidiary.
• Relevant lines, amounts, dates, and classifications are carried forward under controlled rules.

This is the part that sounds straightforward in a meeting but needs careful definition before build. The ERP needs to know which customer maps to which vendor, which subsidiary owns the other side, and whether the transaction should be created immediately or only after approval.

A good automation here does not try to be clever. It should be explicit. It should leave a trace. It should make the paired transaction easy to find. It should also prevent duplicate creation if a user edits and saves the source transaction again.

The Pairing Model Matters

For this kind of automation, the pairing model is more important than the script itself.

At minimum, the source transaction should store a reference to the generated transaction. The generated transaction should also store a reference back to the source. That gives accounting and support teams a simple way to answer the first operational question: what created this?

It also gives the automation a way to protect itself. If the invoice already has a linked bill, the script should not create a second bill. If the linked bill was deleted or voided, the system needs a defined behavior. It can stop and show an error, create a new transaction, or require manual review. The right answer depends on the client’s controls.

The same logic applies in reverse. If a bill creates an invoice, the bill should carry the link. The invoice should carry the reciprocal link. Intercompany automation should be symmetrical in concept, even if the implementation has different details for each transaction type.

Reuse Prior Work, But Do Not Assume Fit

The developer noted that this request is similar to prior work. That matters because known patterns reduce build risk. A previous automation may already handle transaction creation, field mapping, subsidiary logic, or classification defaults.

But reuse should not mean copy and paste. Intercompany AR/AP has its own failure modes:

• The customer-to-vendor relationship may not be complete.
• The target subsidiary may not be derivable from a single field.
• Posting periods may differ between entities.
• Approval status may affect whether the opposing transaction should be created.
• Taxes, currencies, and exchange rates may need explicit handling.
• Edits to the source transaction may or may not update the generated transaction.

These are not reasons to avoid automation. They are reasons to scope it precisely. The call did the right thing by treating this as an operational design problem, not just a development task.

The Segmentation Script Is Part of the System

The conversation also referenced an existing segmentation script. It has already been deployed to several transaction types:

• Company journal
• Bill payment check
• Credit card
• Deposit
• Journal entry
• Vendor bill
• Vendor credit

Expense reports may also need the segmentation script.

This point is easy to miss because it sounds adjacent. It is not. If the intercompany automation creates bills or invoices, those transactions need the same classification discipline as the rest of the ERP. Departments, classes, locations, segments, or other custom accounting dimensions must be populated consistently.

Otherwise, the automation solves one problem and creates another. The AP and AR sides may exist, but reporting becomes harder. The transaction posts, but the dimensions are wrong. The month-end team saves time on entry and loses it on cleanup.

A useful scoping step is to list every transaction type touched by the automation and confirm whether segmentation applies. If it does, the script should either invoke the existing logic or follow the same rules. If expense reports are in scope later, they should be evaluated separately rather than casually added.

The Optional Bulk Payment Interface

The second scoped item was an optional bulk payment application interface. This would be a custom ERP screen where users can select open bills or invoices and apply payments in bulk.

The reason for this request is practical. Applying payments one by one is slow. Using saved searches, reports, or imports can work, but those methods often shift effort from the UI to spreadsheet preparation and exception handling.

A purpose-built screen can reduce that friction. It can show eligible open items, let the user select multiple records, and create the payment applications in a controlled way.

The team also discussed keeping the two sides separate:

• One interface for bills.
• One interface for invoices.

That is a small design choice with a large operational benefit. Combining AP and AR in one screen may look efficient, but it increases the chance that users select the wrong population or apply the wrong process. Separate screens reduce cognitive load and make training simpler.

Partial Payments Need a Decision

Partial payment capability was noted as a possibility. The project lead agreed to confirm with the client whether it is needed.

This is the right kind of question to resolve before estimating too tightly. A bulk interface that only applies full balances is simpler. The user selects open items, confirms, and the system applies payments according to the full remaining amount.

Partial payments change the design. The screen needs editable amounts. It needs validation against open balances. It may need handling for overpayments, discounts, credits, or rounding. It also increases the risk of user error.

That does not mean partial payments should be avoided. It means they should be intentional. If the client regularly pays or receives partial amounts, the interface should support that reality. If partial payments are rare, it may be better to leave them to the standard ERP process.

Estimating the Work

An informal estimate of 10 to 20 hours was discussed for both pieces combined. A more formal estimate was expected back before the agreed deadline.

That range makes sense as an early scoping number if the work follows known patterns and the requirements remain contained. The intercompany transaction creation is familiar. The payment interface is also a common type of ERP customization.

The estimate can change based on a few factors:

• Whether both invoice-to-bill and bill-to-invoice flows are required in the first release.
• How customer and vendor records are mapped.
• Whether approval status controls creation.
• Whether edits to source transactions update the paired transaction.
• Whether partial payments are required.
• Whether the bulk interface needs filtering, role controls, or audit reporting.
• Whether segmentation logic is reused or extended.

A formal estimate should not only give hours. It should state assumptions. That is how the team protects the client and the builder. If the assumptions hold, the estimate is useful. If the assumptions change, the scope can change openly.

Scoping Is Also Attention Management

The call briefly touched on managed services AI demos. The project lead noted that the current approach feels unfocused and is not landing well with clients. No decisions or actions came out of that thread.

That aside is still instructive. Scoping calls work when the team can distinguish the main operational problem from adjacent topics. The intercompany automation had a clear business process, a user pain point, and a likely implementation path. The AI demo discussion did not yet have that shape.

Good delivery teams do not force every idea into the same meeting. They park what is not ready and keep the current decision moving. That is part of how ERP work gets built well.

A Practical Build Sequence

A clean implementation path would likely look like this:

1. Confirm the required flows: invoice to bill, bill to invoice, or both. 2. Define the customer/vendor and subsidiary mapping rules. 3. Confirm which fields copy directly and which fields transform. 4. Decide when the opposing transaction is created. 5. Add source and generated transaction references. 6. Confirm segmentation requirements for each transaction type. 7. Build and test the paired transaction automation. 8. Decide whether the bulk payment interface is in the first release. 9. Confirm whether partial payments are required. 10. Build separate AP and AR bulk payment screens if approved.

This sequence keeps the core accounting automation ahead of the convenience layer. That matters. Bulk payment application is valuable, but it depends on clean open transactions. The paired AR/AP automation creates the foundation.

Ultimately, the value of this work is not that a script creates a bill or an invoice. The value is that the ERP begins to reflect the actual intercompany process without asking users to manually rebuild the other side every time.

What this means for practitioners is simple: the smallest useful automation is often the one that preserves accounting intent across entities. It copies what should be copied, flips what should be flipped, and stops before it guesses.

The takeaway is that ERP automation should be scoped around controls, not shortcuts. When the pairing logic, segmentation rules, payment workflow, and estimate assumptions are made explicit, the build becomes smaller, safer, and easier to support.