By Sachin Bhutani, Sr SAP Finance BPA, KLA

The popularity of software-defined networking (SDN) and network functions virtualization (NFV) has revolutionized the traditional communication network architectures and has transformed the way communication service providers (CSP) design their network infrastructure.  These changes have driven network equipment industry revenue towards product support services and limited term subscription based licensed software delivered in the cloud. With the evolution of business models in the industry, an efficient intercompany accounting model is required to optimize revenue and manage tax liabilities among related entities.

This article explains how existing features and tools in SAP ECC can be leveraged for efficient intercompany accounting for product support services and subscription software. The following aspects of intercompany accounting for service/subscription products will be elaborated on in detail:

• Cross-company invoicing for order-related billing items, where no goods movement is involved
• Intercompany service revenue using SD revenue recognition
• Requirement for inter-company service cost of goods sold (COGS)
• Leverage accrual engine to record inter-company service COGS from IC AP invoices
• Common pitfalls, measures, and other considerations for intercompany service transactions

The models presented in this article can also be optimized for several other industries with little or no modification.

Intercompany Accounting for Support Services and Subscription Software

Networking equipment industry business models are constantly evolving from hardware-driven revenue towards services and subscription-based revenue. Enterprises today are moving away from managing computing and networking infrastructure to anything-as-a-service- (XaaS) based architecture. Therefore, subscription software is an essential and important part of the portfolio for network equipment providers.

Additionally, with the growth of total product installed base at CSPs, product service revenue is a significant and increasing portion of the total revenue for the industry. While services are becoming more important, global supply chain processes—which provide optimal tax structures and revenue optimization to operate at a global scale, for networking equipment hardware sales—need to be applied to product support service and subscription software as well.

Cross-Company Code Invoicing for Order-Related Billing Items

Consider a scenario where company IE01, operating in Ireland, makes a sale of product support service or issues a limited term subscription software license to a customer in Ireland or anywhere else in Europe, while the intellectual property rights on the underlying product and software are owned by a company US01, based in United States.

If it was a tangible good or hardware sale where the goods were being delivered from a plant/depot in the United States, company IE01 can list company US01’s plant on their sales order line item. When a delivery is created for such item and post goods issue (PGI) is complete, SAP ERP records the intercompany sales areas’ details and intercompany customer information in the delivery header table LIKP. Once the customer invoice is issued based on the delivery document, another intercompany customer invoice can be created with standard invoicing transactions VF01 or VF06.

A similar setup of using cross-company code plant can also be applied to product support service, limited term software license, or any other type of material which is not relevant for delivery using order-related billing to create customer invoices. However, in this case, standard settings and configuration alone do not trigger any secondary intercompany invoice after customer invoice is complete.

SAP Note 63459—order and third-party-related intercompany billing outlines the process to create a cross-company invoice for item categories with order-related billing. The following list contains the steps that are discussed in SAP Note 634593, along with some other recommendations.

1. Identify a list of sales organizations, item categories, and customer billing types for which order-related cross-company invoices are required.
2. Identify the intercompany vendor partners, which should invoice the company code selling service to the customer.
3. Create a new output type, such as ZIC0 for invoices and ZIC01 for credit memos. A single output type can also work for both but using different output types provides flexibility for assignment to different billing types and can help identify issues or create reports for reconciliation/ verification of cross-company invoices and credit memos.
4. Create billing types ZIVA and ZIGA as a copy of billing types IVA and IGA, respectively.
5. Create a new pricing procedure and assign to document schema for billing type ZIVA/ZIGA.
6. Create copy of line item copy routine 013 to 913 and maintain routine 913 for copy of item data for all item categories relevant for cross company code service billing in VV32.
7. Copy program RVIVAUFT to a custom program, such as ZOTC_IC_OR_BIL, and change har-coded billing types in the program to new billing types created in previous step.
8. Setup creation of intercompany A/P invoices using EDI as described in SAP Note 31164.

Transfer Pricing

Across multiple countries, any transaction between two related entities is usually governed by the arm’s length pricing principle. For the United States, Section 482-1 (b) of Title 26 – Internal Revenue, defines the principle of arm’s length pricing. Similar principles are established in most other countries and the European Union (EU).

With regards to sale of termed license software or product support service contract, the following two pricing strategies are commonly used:

• Resale minus: In this strategy, to determine the price between intercompany entities, a pre-determined percentage is typically reduced from the net value of the contract with the customer.
• Fixed intercompany price: In this strategy, a pre-determined fixed price per product/service/software is used for the transaction between two entities. Such price may vary based on the combination of entities involved and may be adjusted from time to time, based on cost and accounting policies.

The cost plus pricing principle, where intercompany transfer price is determined by adding a fixed markup to the cost of producing a product, is also commonly used for tangible products, but it is often difficult to use for intangibles as it could be difficult to identify direct cost related to service or software, for example. Additionally, indirect costs could often be more significant than direct cost for such offerings.

Irrespective of the pricing used for transfer pricing, the logic to determine such pricing needs to be built into the new pricing procedure created for cross-company invoicing using steps one through eight outlined earlier in this article. Additional configuration and customization may be needed for determination of taxes and/or import duties, if applicable.

Intercompany Revenue and COGS

Sales revenue for product support services or term software licenses is distributed over the length of the contract or license, based on the start and end date of the service or subscription. Revenue recognition category A – time based revenue recognition–is used to achieve this behavior using SD-Rev Rec module6. Cross-company invoices created for such offerings would also need to post monthly revenue recognition entries for multiple periods in the future depending upon the length/term of the contract for intercompany revenue. Typically, customer invoices for product support services or term software licenses do not require posting of any COGS component, however once cross-company code invoicing is activated for such items, intercompany revenue would be recorded on each cross-company invoice. To eliminate the intercompany revenue at the consolidated group or region level of the organization, it’s important to record offsetting intercompany COGS for each transaction.

Cross-company billing does not automatically copy over the revenue recognition category from sales order to intercompany invoice, even when copy control is maintained between the sales order and invoice type. Additional logic needs to be added to copy the field value for VBKD-RRREL to the invoicing document in the copying requirement routine 913 created in steps one through eight earlier in this article. Copying the value for field VBKD-RRREL enables generation of monthly revenue recognition documents using SD-Rev Rec for time based revenue recognition category A.

SD-Rev. Rec. also has functionality to post COGS entries for each period, but this functionality cannot post to two different company codes from a single invoice document. To record periodic intercompany COGS posting, accrual engine functionality can be leveraged. For details of accrual engine functionality, refer to attachments in SAP Note 63394- Accrual engine: Additional documentation.

To leverage the accrual engine, a cost accrual document needs to be created with reference to each intercompany AP invoice. A cost accrual document can be used to post monthly from an ‘accrued COGS account’ to ‘realized COGS account’. This monthly COGS posting in company IE01 completely offsets the intercompany revenue recorded in company US01.

To record a cost accrual document in the accrual engine component, use IMG configuration path SPRO -> Financial Accounting New -> General Ledger Accounting (New) -> Business Transactions -> Manual Accruals or transaction code ACACIMG and take the following steps:

1. Assign company codes where IC COGS posting is required to component ‘ACAC’, company code IE01 in the out illustration. Customization object: V_TACE001_BUKRS
2. Assign the company codes (IE01) to relevant accounting principle (GAAP) using customization object V_TACE_COMBINATN.
3. Update the last closed fiscal year for each co code in customization object V_TACE001_ACAC
4. Create an accrual object category, for IC COGS entries “ZICCOGS” – Intercompany service COGS
5. Create number in each company code for:
   1. Accrual object, using customization object ACAC_NUMOBJ
   2. Periodic posting runs, using customization object ACAC_ACEPS_RUNID
   3. Accrual engine documents, using customization object ACAC_ACEPS_ACEDOCNR
6. Create a new accrual method “LIN360” with function “FILAFM_DMETHOD_LINEAR_D3” – this method allows for a liner distribution “Linear Distribution of an Amount, for a Specific Date, Basis: 360 Days”
7. Assign deferral method “LIN360” to the combination accounting principle GAAP and accrual type “COSTSP” – Cost Accruals, Only Periodic Postings, in customizing object V_TACE_DS_C_ACAC

To verify the setup, a manual accrual object can be created or simulated with transaction “ACACTREE01.” To simulate an accrual object document, enter the following:

• Accrual object category: ZICCOGS
• Company code: IE01
• Start of life: 01/01/2020
• End of life: 12/31/2020
• Add an accrual item with accrual type COSTSP
• Add accounting principle GAAP
• Add amount to be accrued, currency and accrual method “LIN360”
• Add GL accounts in the periodic posting section for deferred COGS and intercompany COGS with document type SA

Posting can be simulated to verify the amounts. On saving the document, a cost accrual document is created.

The accrual document itself does not create any GL posting as only periodic posting accrual type “COSTSP” is recommended. To post the periodic/monthly COGS, transaction code ACACACT should be used. ACACACT can be scheduled as a batch job to automatically post all accruals for a company code on a scheduled basis to debit deferred/accrued COGS account on the vendor invoice and credit the intercompany COGS account.

Transaction code ACACDATATRANS, program ACAC_DATA_TRANSFER_EXAMPLE, provides an example to automate creation of cost accrual documents directly from vendor invoices. The sample program needs to be copied and customized to select relevant intercompany invoice documents, copy over the amount from IC A/P invoices, copy over the relevant accrual start and end dates from the original customer invoice or sales order, and then automatically create accrual documents.

Process Overview

The entire intercompany process for service/limited term software subscription is illustrated in Figure 1 and can be summarized with the following sequence of steps:

1. End customer invoice creates SD-Rev Rec entries for posting of deferred service revenue in company code IE01 on a monthly recurring basis.
2. Output from end customer invoice is leveraged to create I/C AR invoice for service transactions using cross company invoicing for order related billing items feature.
3. Pricing procedure setup is used to create I/C AR invoice based on transfer price arrangement between related entities, which could be based on end customer invoice price.
4. The I/C AR invoice creates entries into SD- Rev Rec tables, for periodic posting of intercompany service revenue in co code US01.
5. An I/C AP invoice is created with intercompany EDI process in co code IE01.
6. I/C AP invoice is paid and settled between IE01 and US01.
7. A custom program based on ACACDATATRANS is used to create I/C COGS accrual documents from I/C AP invoices.
8. Transaction ACACACT posts monthly IC COGS in co code IE01 to offset IC service revenue in co code US01.

Other Considerations

• To aid with reconciliation of intercompany A/R invoices and intercompany A/P invoices created with electronic data interchange(EDI), it’s helpful to copy the intercompany A/R SD billing document number first into the reference field on the A/R document through standard configuration in copy control settings, and then copy the reference number into intercompany A/P FI document. This allows for utilization of intercompany reconciliation process 001, with reference field for reconciliation of AR/AP items.
• If the same SAP SD billing document type is used for both forward customer invoices and customer invoice cancellation, then either single output type may be used instead of ZIC0 and ZIC1. Or, requirement routines can be added to trigger only the relevant output type based on whether the document is forward customer invoice or a cancellation.
• It’s important to consider how cancellations of customer invoices are treated. One efficient way to do this is to add output type ZIC1 to cancellation document types.
• The design presented in a multi-party scenario has also been successfully implemented with a multiple intercompany partner scenario, where each customer sale results in two subsequent intercompany invoices. Identification of inter-company customers and sales areas for one of the parties needs to be maintained with a custom table and then updated in programs ZOTC_IC_OR_BIL to refer to custom table entries. Pricing procedure settings also need to be updated to reflect the correct pricing between all intercompany partners involved. Other processes, such as creation of cross company invoices for order related billing items and creation of intercompany COGS accrual documents, can be used without significant modifications.

About the Author

Sachin Bhutani is an SAP Financials consultant with over 15 years of experience across multiple industries spanning consumer packaged goods (CPG), utilities, hi-tech equipment, media, and semiconductors. Sachin has vast experience on multiple financial transformation projects and has worked with clients across North/South America, Asia-Pacific, Europe, Middle East and Africa. Sachin has specialized expertise in intercompany accounting along with detailed working knowledge of integration with order-to-cash, procure-to-pay and stock-transfer processes into financials. He holds a Master’s Degree in Business Administration and Finance and a Bachelor’s Degree in Information Technology. You may contact Sachin at sachin@bhutani.xyz.