Org structure, chart of accounts and master data harmonization

Once the target state is fixed, the integration becomes a long list of mapping decisions. Which company code, which controlling area, which chart of accounts, which profit centers, which number ranges, and which of the target's customers and suppliers are already the buyer's business partners? SAP enforces some of these choices through hard constraints; others are design decisions that finance and the process owners must make on purpose. This lesson walks through both, using Contoso's company code 1910.

Fitting the target into the organizational structure

Contoso's controlling team assigned 1910 to controlling area A000, alongside 1710 and 1810. That decision brings two constraints. All company codes in a controlling area use the same operating chart of accounts, so 1910 posts to Contoso's accounts, not to Alternadores' legacy accounts. And the fiscal year variant of 1910 must match A000's; in SAP S/4HANA, finance and controlling share the Universal Journal (table ACDOCA), so the variants must be identical. Alternadores closes on the calendar year, so it fits. A target with a different year-end would need either a fiscal year change before the load or its own controlling area, and SAP's fiscal year conversion for a live system is a DMLT scenario, not a setting.

Chart of accounts and statutory needs

Mapping a target's accounts to the buyer's chart is normally n:1: several legacy accounts land on one Contoso account. A 1:n split, where one legacy account must spread across several target accounts, cannot be done by a simple mapping table. It needs a rule on another attribute, such as splitting legacy sales by customer group into domestic and export revenue, and the rule must be written, tested and reconciled. SAP LT's chart of accounts conversion follows the same logic: rename and n:1 merge are possible, splitting is not.

Local requirements sit beside the group chart. Mexico expects electronic accounting files that map each account to the tax authority's grouping code; check SAP's Mexico localization for your release to see how that mapping is maintained, and include it in the mapping workbook rather than in a spreadsheet on someone's laptop. Contoso already runs document splitting by profit center and segment, so every 1910 line item also needs a profit center: decide early whether Monterrey gets its own profit centers or derives into existing ones, because that decision changes segment reporting.

Business partners: merge, extend or create

Alternadores has 3,180 customers in its legacy ERP, of which 1,946 are in scope. Some suppliers overlap with Contoso's: if Lakeside Components also supplies Monterrey, the right answer is to extend the existing business partner 17300001 with company code 1910 and purchasing data, not to create a second Lakeside. Contoso itself appears in Alternadores' customer list, and Alternadores appears as a supplier in 1710; after the deal those relationships are intercompany, so the business partners need the trading partner set to the right company. Customers that look identical can still be separate legal entities, such as two fleet operators sharing an address in an industrial park, so duplicate matching needs human review.

Keep the legacy number traceable. Migrated customers and suppliers get Contoso business partner numbers, so store the legacy number in the customer's and supplier's company code data (the previous account number field) or another agreed reference, and make it searchable. Finance and auditors will ask "what happened to legacy customer 40112?" for years.