Client Case Study
From Legacy Accounting to Business Central: Configuring Intercompany Operations Across Five Entities in Southeast Asia
How a Southeast Asian environmental technology group went from a legacy accounting system to a fully integrated, multi-entity ERP — and what the journey looked like from onboarding to ongoing support.
5
Legal Entities
4
Countries
3
Months Active
3
Work Streams
The Client
An environmental technology group headquartered in Southeast Asia and operating across four countries in the region. The group comprises five legal entities spanning manufacturing, recycling, and environmental services.
The client had recently migrated from a legacy accounting system to Microsoft Dynamics 365 Business Central (Essentials) with a single licensed user responsible for the accounting operations across all five companies. The migration brought them onto a modern cloud ERP, but the post-migration configuration — particularly the intercompany setup needed to manage transactions between their entities — had not yet been completed.
The Challenge
The core problem was deceptively simple on the surface: "We need our five companies to transact with each other in Business Central." In practice, this meant solving several interconnected challenges simultaneously:
Intercompany complexity. Five entities means up to twenty possible intercompany relationships. Each direction of each relationship requires its own customer card, vendor card, posting group, and GL account mapping. A single misconfiguration in any of those layers means transactions post to the wrong accounts — or fail entirely.
Multi-currency operations. The entities operate in different functional currencies across four jurisdictions. Foreign currency setup had to support not just third-party transactions but also intercompany settlements, each with their own exchange rate considerations.
Posting group architecture. The GL structure inherited from the legacy migration needed a posting group configuration layer that would cleanly separate intercompany transactions from third-party transactions — both for reporting accuracy and for audit readiness.
One user, five companies. With a single licensed user managing all five entities, the configuration had to be intuitive enough for day-to-day operations without requiring constant partner intervention. Any setup that demanded deep BC expertise to maintain would fail in practice.
The Engagement
The client engaged GV Prime under a standard support agreement. The work was broken into three discrete work streams, each scoped, estimated, and tracked independently.
Work Stream 1
Master Data Management & IC Partner Setup
The foundation. This covered the Intercompany Partner Code configuration for each entity, the IC Chart of Accounts mapping between companies, and the IC General Journal template setup. The goal was to establish the plumbing that would allow any entity to initiate an intercompany transaction with any other entity. A self-service guide was delivered alongside the configuration — a PDF reference document enabling the client's user to navigate IC operations independently post-engagement.
Work Stream 2
Foreign Currency Setup
Multi-currency configuration covering exchange rate services, currency codes, and the posting rules needed for cross-border intercompany transactions. Five of six validation tests passed on first attempt; the sixth was blocked by a posting group dependency that was resolved in the next ticket.
Work Stream 3
Posting Group Configuration
The most technically dense ticket. Customer and Vendor Posting Groups had to be created for every intercompany relationship across all five companies, ensuring that IC receivables and payables routed to the correct GL accounts — distinct from third-party trade balances. The configuration was validated with end-to-end test transactions covering purchase invoices, sales invoices, and intercompany journal entries, with all test data reversed after validation.
28
Posting groups configured
20
IC partner linkages
Result
All three work streams closed within the agreed support period. Every deliverable was completed, and every configuration was validated with test transactions and documented evidence.
Post-Block: The Relationship Continues
When the initial support agreement concluded, the client chose not to renew immediately. For many managed service providers, that would be the end of the conversation. For us, it was the start of a different phase.
Advisory Support
We transitioned the client to our advisory tier — a best-effort, non-billable guidance channel available to clients with active subscriptions in good standing. When the client's user encountered unfamiliar BC behaviours (IC Inbox pages appearing empty, journal fields not visible by default, or error messages when posting IC transactions), we provided step-by-step advisory guidance to help them self-resolve.
This is a deliberate part of our model. We believe that staying accessible after a formal engagement ends is how you build a partnership, not just close a project.
Standing Behind the Work
Several weeks after the block closed, additional intercompany configuration needs surfaced — customer and vendor records for transaction flows that hadn't been part of the original delivery. Rather than draw hard lines around a scope document, we treated complete intercompany coverage as our responsibility and delivered the additional configuration at no charge.
Our Standard
The client expected a complete intercompany setup, and that is what they got. A working system matters more than a scoping technicality.
The follow-up work was substantial — additional customer and vendor records across four companies, 28 posting groups, 20 IC partner linkages, and a full validation suite. Along the way, we identified that several reported behaviours were actually standard Business Central design (for example, the IC document flow is seller-initiated — purchase invoices do not automatically generate IC Outbox entries). We documented those findings and shared them transparently.
Every step was tracked in a detailed audit log — over 400 lines of timestamped evidence covering before-states, configuration changes, test results, and reversals. Every claim in our completion summary was verified line-by-line against the audit log before sending.
Emerging Requirements
With the IC foundation in place, the client's needs have continued to evolve. Recent advisory requests have included SharePoint integration with Business Central and sandbox environment provisioning — the kinds of operational maturity questions that naturally follow a successful ERP configuration engagement.
These are the kinds of questions that naturally follow a successful foundation — and they come to us because the first engagement gave them confidence that the work would be done properly.
What We Learned
Scope Early, Scope Precisely
The follow-up round originated from a scope boundary that was clear in our internal documentation but ambiguous from the outside. Now, every phase description in our scoping documents maps one-to-one against the internal playbook — no paraphrasing, no summarisation that might add or remove scope items. Acceptance criteria are explicit, and dependencies on client-provided input carry a clear description of what happens if that input is not provided.
Verify Before You Assert
During the follow-up work, we initially inferred that a vendor card was missing its IC Partner Code because IC auto-send was not triggering on purchase invoices. Direct inspection of the card proved the Partner Code was correctly configured — the actual root cause was standard BC behaviour (seller-initiated IC flow). The lesson: always verify root causes directly, never infer them from symptoms. This principle now applies to every factual claim in every client communication we send.
Document Everything, In Real Time
Our audit logging protocol — timestamped entries for every configuration change, test result, and client decision — is not bureaucratic overhead. It is the single source of truth that protects both us and the client. When a client questions what was done and when, the audit log answers definitively. When drafting client emails, the log is the grounding reference that prevents assumptions from becoming assertions.
Stay Present After the Engagement Ends
Providing best-effort advisory guidance to a client after a formal support agreement ends might look like giving away time. In practice, it is how you stay relevant. The client's needs do not stop evolving when an engagement ends — and being the partner they turn to when new questions arise (intercompany training, document flow automation, SharePoint integration) only happens if you stayed present after the formal engagement closed.
The Ongoing Partnership
Today, the client runs a fully configured intercompany environment across five entities in four countries on Business Central. Their single licensed user can post IC transactions, manage multi-currency operations, and navigate the system with a self-service guide built specifically for their setup.
The subscription is active. Advisory access continues. New requirements surface regularly. And when the client is ready for the next phase of configuration work — whether that is IC training, document flow automation, or SharePoint integration — the relationship, the documentation, and the audit trail are all in place to pick up exactly where we left off.
By the Numbers
Five legal entities across four countries. Three structured work streams. Twenty-eight posting groups. Twenty IC partner linkages. One self-service guide. Zero unresolved configuration issues. One ongoing partnership.
Running Business Central Across Multiple Entities?
Whether you are post-migration and need intercompany configuration, or looking for a managed support partner who documents everything and stands behind the work — let's talk.
This case study has been anonymised to protect client confidentiality. All technical details and outcomes are based on documented project records. More case studies →