Find out about the main organizational units of SAP In-House Cash and understand the three core payment processes this component supports, including their differences. Learn the business configuration of the application and the functional differences that were introduced with SAP ERP. Follow the step-by-step technical implementation of Application Link Enabling to enable Intermediate Document communication within SAP In-House Cash.
Key Concept
SAP In-House Cash allows corporate cash and treasury management departments to set up a payment factory and to centralize their payment flows. One of the challenges is that the business processes of SAP In-House Cash span multiple financial components and require a broad set of business and technical skills.
Maintaining corporate liquidity, securing sufficient capital cushions on the balance sheet, and saving operational costs are the primary goals for many cash management and treasury organizations. Global companies with multiple affiliates face challenges such as changing corporate structures, manual payment and reconciliation processes, high costs of cross-border payments, and high transaction volumes with multiple bank connections.
SAP In-House Cash can help you overcome these challenges by centralizing group cash flows and establishing an in-house bank. SAP In-House Cash helps you:
- Reduce your transaction volume of payments by netting payment flows between your subsidiaries
- Avoid value date losses by keeping cash flows within your company
- Decrease the number of physical bank connection and banking fees by setting up subsidiaries as in-house bank accounts
- Limit exchange rate risks by concentrating currency exposures of your affiliates within your group
- Implement global and standardized business processes by using the standard payment and account statement programs in the SAP system
- Get a faster overview of your liquidity position and achieve a higher degree of transparency of your cash flows
Little documentation is available from SAP and very few consultants are aware of or familiar with how SAP In-House Cash can help you solve these problems. I’ll look into this in detail, starting with organizational entities before moving on to the business processes.
Organizational Entities within SAP In-House Cash
With SAP In-House Cash, the headquarters of an international company creates a virtual in-house bank — known as the in-house cash center (IHCC) — to process all payment transactions between the subsidiaries and their external business partners. Five organizational entities are important in this context (Figure 1).

Figure 1
Organizational entities in SAP In-House Cash
- Subsidiaries and affiliated companies: Subsidiaries are independent business units that have implemented their own SAP or non-SAP system. From the headquarters view, these subsidiaries are company codes. For a subsidiary, the IHCC serves as its house bank.
- The headquarters: The headquarters, or an organizational unit assigned to the headquarters, includes the FI functions of SAP ERP Financials and the IHCC. The headquarters’ FI system manages the current accounts of the subsidiaries and draws up the balance sheet for the headquarters, which also considers the IHCC. Payables and receivables between the IHCC and the subsidiaries are posted as aggregates on General Ledger accounts in the headquarters’ FI system. A receivable of the IHCC represents an obligation of the subsidiary and vice versa. The IHCC functions as a bank for the entire group to manage the current accounts of both the headquarters and the subsidiaries. The IHCC is responsible for processing payments and regularly dispatching bank statements to the subsidiaries. The IHCC is represented by the bank area, which is the central organizational entity in the SAP system. All the SAP In-House Cash accounts are managed and all relevant postings are carried out within the bank area.
- House banks used by the headquarters: These house banks are not part of the enterprise structure, but the IHCC uses them for the external payment processes of SAP In-House Cash.
- External business partners (e.g., suppliers and customers): These business partners send or receive payments to and from suppliers or customers.
- The house or partner banks of these external business partners: These house banks receive payments from the IHCC and send account statements back to the IHCC.
Business Processes within SAP In-House Cash
Now that you know the basic organizational entities within SAP In-House Cash, let’s take a closer look at the three most important business processes:
- Intragroup payments: Payables and receivables between subsidiaries are cleared within the group automatically
- Outgoing central payments: Payments to external business partners from the subsidiaries are settled by the IHCC on their behalf
- Incoming central payments: IHCC receives incoming payments from external business partners centrally and forwards them to the subsidiaries
SAP In-House Cash uses Intermediate Documents (IDocs) for the communication between the subsidiaries and the IHCC. The two IDocs that SAP In-House Cash uses are PAYEXT (basis type PEXR2002) for payment orders and FINSTA (basis type FINSTA01) for account statements. You can see the structure of these IDoc types by following the user menu path Tools > ALE > ALE Development > IDoc > IDoc Type Development > IDoc Types (Figure 2).

Figure 2
IDoc type FINSTA01
Let’s now take a closer look at the technical and account determination consequences of the three core business processes of SAP In-House Cash. In each scenario, I’ll simplify the processes by assuming that you have two subsidiaries, A and B, and one IHCC.
Intragroup Payments
I’ll start with intragroup payments, for which you can follow a sequence of business steps related to Figure 3.

Figure 3
Business steps for intragroup payments
Step 1. Subsidiary A delivers goods or services to subsidiary B and sends an invoice to subsidiary B. Subsidiary A posts this invoice to AR and subsidiary B to AP, making accounting record a in Figure 3.
Step 2. Subsidiary B initiates a payment run in AP to clear the open item and post it on the SAP In-House Cash clearing account. The system creates a payment file with a PAYEXT IDoc and sends this IDoc to the IHCC (accounting record b).
Step 3. The IHCC accepts the incoming PAYEXT IDoc automatically, debits the current account of subsidiary B, and credits the current account of subsidiary A. The IHCC now has a claim against subsidiary B and an obligation against subsidiary A (accounting record c).
Step 4. The IHCC periodically creates account statements for the two subsidiaries as a FINSTA IDoc. Subsidiary B imports the account statement and clears the SAP In-House Cash clearing account (accounting record d1). In subsidiary A, you can see two postings: one on the SAP In-House Cash clearing account and another to clear the debtor and clearing account (accounting records d1 and d2).
Step 5. The IHCC transfers the aggregated documents to the General Ledger of the headquarters (accounting record e).
Intra-company processes — including not only intra-company payments, but also reconciliation processes, the creation of account statements, and so on — are quite easy to implement and I recommend you start first with them before implementing more sophisticated processes.
Outgoing Payments
Outgoing payments are more complex because they require a real cash flow and not just the netting of receivables and payables. For this business process, you need a clearing partner in the headquarters that processes the external payment via its external bank account. Both the subsidiary and this clearing partner have a current account in SAP In-House Cash. SAP introduced this technical clearing partner account with release SAP ERP 5.0 and changed the previous posting logic of SAP In-House Cash. You can follow a sequence of business steps for the outgoing payments scenario in Figure 4.

Figure 4
Outgoing payments in SAP In-House Cash
Step 1. Subsidiary A receives goods or services from an external business partner and an invoice. Subsidiary A posts this invoice to AP and initiates a payment run to clear the open item against a bank clearing account. The system creates a payment file with a PAYEXT IDoc and sends this IDoc to the IHCC (accounting record a).
Step 2. Having received the PAYEXT IDoc, the IHCC debits the current account of subsidiary A and credits the current account of the clearing partner that executes the payment on behalf of subsidiary A (accounting record b). The IHCC also forwards the payment order for the external business partner by creating another PAYEXT IDoc. In this case, it’s not a payment order, but a payment request that is processed in step 5 by transaction F111. You use this payment request to release the external payment to the external business partner.
Step 3. The IHCC periodically creates account statements for the clearing partner account and the IHC account of subsidiary A. Both account statements are again posted automatically in the FI systems of the headquarters and the subsidiary A. The bank clearing account in the system of subsidiary A is cleared and posted against the SAP In-House Cash bank account (accounting record c1). The clearing partner posts a receivable item on an SAP In-House Cash clearing account against a payment request account that is later cleared by the external payment (accounting record c2). Remember that you haven’t paid the external business partner yet.
Step 4. The IHCC transfers the aggregated documents to the General Ledger of the headquarters. There are more postings needed in this scenario. First, debit subsidiary A and post a credit on the technical account of the clearing partner (accounting record d1). The headquarters has a receivable against subsidiary A now. In this simple scenario, the clearing partner and the organization operating the IHCC are the same and you don’t need to consolidate the liabilities of the IHCC against the clearing partner. You can simply clear the technical account and the IHC clearing account (accounting record d2).
Step 5. The IHCC initiates the payment to the external business partner using the payment request payment run. This transaction creates a payment file for the external house bank and clears the payment request account, creating in parallel a credit entry on the house bank clearing account of the clearing partner (accounting record e).
Step 6. The headquarters receives the account statement from the house bank of the clearing partner that clears the house bank clearing account and posts a credit on the house bank account (accounting record f).
You can technically track the successful processing and sending of IDocs in this and all the other scenarios I presented by using transaction WE02 or by following the user menu path Tools > Administration > ALE > ALE Administration > Monitoring > IDoc Display (Figure 5). This is useful for testing the SAP In-House Cash scenarios during the implementation.

Figure 5
IDoc monitor
Incoming Central Payments
The third important business process in SAP In-House Cash is the opposite of the previous outgoing payments scenario. In this case, you use the external bank accounts of the clearing partner to centrally collect external payments from customers. You can also use this scenario to pool your cash across the group. You can follow a sequence of business steps for incoming central payments (Figure 6).

Step 1. The clearing partner or the operator of the IHCC receives an external payment for subsidiary A, which is posted via the account statement on the bank account, and the bank clearing account of the clearing partner (accounting record a). The trigger for this posting is a specific reference number in the account statement.
Step 2. Since the incoming payment is relevant for SAP In-House Cash, it is automatically assigned to the SAP In-House Cash current account of subsidiary A. The SAP system automatically creates a payment order that credits the SAP In-House Cash account of subsidiary A and debits the clearing partner’s SAP In-House Cash account (accounting record b).
Step 3. The IHCC periodically creates account statements for the IHC account of subsidiary A and the clearing partner account. The incoming account statement (as FINSTA IDoc) is posted on the IHC account of subsidiary A and clears the bank clearing account. In addition the debtor account of subsidiary is cleared (accounting record c1). The account statement for the clearing partner clears the initial posting on the bank clearing account against the SAP In-House Cash clearing account (accounting record c2).
Step 4. The system transfers the documents again to the General Ledger of the headquarters. Similar to the previous process, the technical clearing account is debited and credited. The documents are posted against the payables account and the SAP In-House Cash clearing account (accounting records d1 and d2). Subsidiary A has a payable for the headquarters now.
There are two other business processes that are less common: outgoing local payments and payments via multiple IHCCs. You can read the basic concepts about them in the sidebar “Two Less Common Business Processes.”
Enterprise Services as an Alternative to IDoc Communication
In all the SAP In-House Cash business processes, I used the IDoc types FINSTA01 and PEXR2002 to transfer payments and account statements between subsidiaries and the IHCC. The two underlying SAP technologies, Application Link Enabling (ALE) and Remote Function Call (RFC), are stable but also have certain limitations. They cannot, for example, contain more than 9,999 line positions and the available PAYEXT IDoc doesn’t allow multiple payments. Another potential issue is a heterogeneous system landscape when non-SAP systems connected to SAP In-House Cash aren’t capable of producing or processing IDocs.
To overcome these limitations, SAP introduced two SAP NetWeaver Process Integration (SAP NetWeaver PI) messages with SAP ERP 6.0 as application-to-application (A2A) service-oriented architecture services that facilitate the data exchange with non-SAP systems. The two A2A message types are called CollectivePaymentOrderRequest and BankAccountStatementNotification. You can find them in the Enterprise Services Repository in the package EA-FINSERV (Figure 7).

Figure 7
SAP NetWeaver PI message type CollectivePaymentOrderRequest
If you have maintained the Integration Directory and the System Landscape Directory of SAP NetWeaver PI you can activate these two message types in SAP In-House Cash. To do this, you have to define entries for inbound payment order requests received by the SAP NetWeaver PI interface by following IMG path Financial Supply Chain Management > In-House Cash > Account Management > Payment Processes in In-House Cash > Define Transaction Type for Automatic Payments. In addition, you have to change the account statement format that is created by the IHCC by changing the settings of the respective IHC accounts in the SAP menu (Figure 8).

Figure 8
Configuration of SAP NetWeaver PI account statement formats
Two Less-Common Business Process
Global organizations can implement two less-common In-House Cash business processes as well: local payments and payments across multiple bank areas. I won’t describe the details of these processes in this article but rather explain briefly their purpose.
Local payments were introduced as a new process with SAP ERP 5.0. This is again an outbound scenario in which payments to external business partners are made by one subsidiary to settle amounts payable on behalf of another subsidiary. Let’s assume your US subsidiary receives occasional services from an external business partner in the UK and you would use your UK subsidiary to settle the invoice via its local bank account. There are two main benefits of this scenario: You avoid high bank fees for cross-border payment transactions and you don’t have to bear the foreign exchange risk. The main difference between local payments and outgoing payments is that the clearing partner (in this example, the UK subsidiary) isn’t running the IHCC.
In all my examples, there has been only one IHCC and all payments were executed within one bank area. It might make sense for you to set up multiple IHCCs, for example for different geographies such as America, EMEA, and Asia. In this case, you would have multiple bank areas and payments would be executed across multiple bank areas. The main difference of this scenario is that each IHCC also maintains a specific clearing account for the payment transactions between the different bank areas.
Juergen Weiss
Juergen Weiss works in the functional area of SAP Financial Supply Chain Management. As part of SAP’s product management team, he was globally responsible for the Financial Supply Chain Management applications, including Electronic Bill Presentment and Payment, Dispute Management, Collections Management, Credit Management, Treasury and Risk Management, Bank Relationship Management, and In-House Cash as well as Accounts Payable and Receivable.
You may contact the author at juergen.weiss@sepa-now.de.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.