SAP In-House Cash (IHC)

SAP In-House Cash (IHC) is SAP's module for running an internal bank — maintaining internal accounts for group subsidiaries and processing payments between and on behalf of them, so the group banks internally instead of externally. It's the SAP implementation of the in-house bank concept this site covers generally, and it's where a centralized treasury operating model becomes concrete inside SAP.

SAP's own documentation states the payoff in one sentence, and it's the sentence to quote in a business case: In-House Cash is used for processing internal and external payment transactions within a group, and by using it "you can reduce the number of external bank accounts you hold and the volume of foreign payments you have to make." That is the whole thesis. The rest of this page is the named objects underneath it — bank areas, payment orders, tables, BAdIs, archiving objects and the newer In-House Banking apps — verified against SAP Help rather than reproduced from the scraped lists this topic attracts.

What it is, in SAP's own structure

The main component is the in-house cash centre: SAP describes it as "basically a virtual internal bank where subsidiaries hold current accounts". Current account processing depicts the receivables and payables between the centre and its affiliated companies, calculates turnover and balances, and forwards that information in summarised form to Financial Accounting. That last clause matters more than it looks: the general ledger sees summarised current-account movement, not one FI document per internal payment, which is why the intercompany reconciliation design has to be deliberate rather than emergent.

Four transaction categories are documented, and getting your scope statement to name them explicitly saves a lot of later argument:

• Internal payments — between group entities, across internal accounts
• Central payments — the centre pays externally on a subsidiary's behalf
• Local payments — settled locally between clearing partners
• Central incoming payments — collections arriving centrally and credited internally

Payment orders don't only arrive by hand. SAP documents three automatic origins — an inbound IDoc from a subsidiary system, an external bank statement, or Treasury Management — and tells you where to look when you can't tell which: the Input Channel field in the payment order's management data.

You can run more than one centre. SAP is explicit that you "can decide to implement one or more in-house cash centres within your group of companies", which is the usual answer to regional-treasury structures.

The organisational object: the bank area

If one concept is worth learning before you open the IMG, it's this one, because IHC does not invent its own account infrastructure — it borrows Bank Customer Accounts (BCA):

The bank-area Customizing sits in BCA, not in IHC, and SAP names what you set there: the bank key, the check digit method controlling account-number issuing, the daily posting cut-off time, the exchange rate category, and the country, language and holiday calendar. The holiday calendar is the one that quietly breaks value dating in month one.

One operational consequence worth reading twice: when a feeder system transfers payment items, the bank area is determined from the bank key. If a payment item is forwarded to the system by BAPI and the bank area cannot be determined, SAP documents that the BAPI terminates with a system-error return code and no items are processed — a whole-batch failure, not a per-item one.

Configuration: where the settings actually live

That last row is not filler. SAP Help documents this module by menu path and Customizing node, not by transaction code — which is precisely why the tcode-dump sites are so confident and so unreliable here. See the exclusions at the end.

The tables, and how SAP names them

The treasury tables reference deliberately excluded In-House Cash, on the grounds that it's a different component with its own family and mixing them is how those 400-row dumps became unusable. Here is that family, taken from the place SAP actually publishes it — the documentation for archiving object IHC_ARC:

The same archiving run also touches the generic application-log and change-document tables — BALDAT, BALHDR, BAL_INDX, CDHDR, CDCLS, CDPOS_STR, CDPOS_UID — which tells you something useful about IHC's audit trail: the change history is standard change documents, so it is reportable with the tools you already have.

Archiving is where the current-account side becomes visible, because it has its own object set:

Three details from the IHC_ARC documentation that belong in a retention design rather than being discovered during an audit: payment orders can only be archived when their final status is Final, Posted, Deleted or Reversed; ILM-based archiving requires them to be blocked by program IHC_APPL_BLOCK_PN with business function FIN_IHC_ILM active; and the ILM condition fields are the IHC bank area and the IHC payment order status, with the retention period counted from the last-changed date (or the creation date, if the order was never processed after creation).

The extension points

Custom requirements in IHC land on a small, documented set of BAdIs. Knowing them turns "can we do X" from a research project into a lookup:

IHC_BADI_IDOC_2_PN and IHC_BADI_XBS_TRNS are the two that show up in almost every implementation, because both sit exactly where a real-world file meets an idealised configuration table.

Where the Transaction Manager plugs in

Treasury deals settle through IHC by a documented route rather than by accident. SAP provides the BAdI TPM_EXT_PAYMENT_TRPR for connecting payment programs to the Transaction Manager, and ships an example implementation named HC_CFM_ADAPTOR, delivered inactive, that realises the connection to In-House Cash. SAP's own recommendation is not to activate the example directly but to create your own implementation that calls its methods — and the method that decides per payment is IS_RELEVANT: return X and the payment goes through In-House Cash, otherwise it is processed as a payment order.

Two things follow. First, treasury payments to IHC run on payment requests, not customer-account postings — SAP states that if you want to process a payment using In-House Cash, payment is done using payment requests, which is the same F111 world treasury settlements already live in. Second, the generated payment orders are visible from the treasury side, in the posting journal and in the transaction's cash flow, so the audit trail from deal to internal account is a navigable one.

Payments on behalf of, and the APM boundary

The modern payments-on-behalf-of flow runs through Advanced Payment Management, and SAP documents the mechanics precisely enough to design against. The subsidiary's payment run posts to an in-house bank clearing account per its payment method setup, and generates at least two IDocs — PEXR2003 and PAYEXT — which are sent to headquarters' APM. There they become an APM payment order with one originator item and the recipient items; enrichment and validation, then routing and clearing, determine which house bank pays what, and additional outgoing orders are created per bank with the clearing item on that bank's clearing account.

One configuration fact worth knowing before someone promises it in a workshop: payment on behalf of inside the same company code is deactivated in the standard system and can be activated only via a BAdI in Routing Control. This is the SAP-side detail behind the payment factory versus in-house bank distinction, and the external leg still leaves through Bank Communication Management.

The other In-House thing: In-House Banking (IHB)

This is the trap in the topic, and it is worth being pedantic about because the two names differ by one word. In-House Banking (IHB) is not a rename of In-House Cash. SAP documents it as "an embedded capability of advanced payment management" for SAP S/4HANA Cloud for advanced payment management, usable only within APM, in which subsidiaries open internal bank accounts that behave, from the subsidiary's side, like house bank accounts.

It is Fiori-first, and unlike classic IHC it has app IDs you can verify:

Its own archiving objects follow the /PF1/ namespace. /PF1/ACCT (accounts) and /PF1/ACBL (account balancing data) each have their own SAP Help page, cited below; the siblings listed alongside them in that section of SAP's documentation cover account limits, financial conditions, statements and the destruction of end-of-day logs. Read the section rather than assuming an object name — this namespace is where SAP puts the in-house-banking counterparts of the IHC objects above. Two capability notes from SAP's page that decide designs: conditions resolve in a fixed order — single, then group, then bank area level — and the electronic bank statement produced by in-house banking is, in SAP's wording, a "CAM.053 message", with "further formats not yet available". If your subsidiaries need MT940 from the internal bank, that is a gap to plan around, not a setting to find.

The prize, and the catch

The prize is the in-house bank prize, and now you can quantify it from SAP's own framing: fewer external accounts to hold, fewer foreign payments to make, cash concentrated centrally, internal settlement instead of external payments. The catch is the same one that shadows all of this — intercompany accounting. Every internal transaction and on-behalf-of payment generates intercompany balances that have to be tracked, reconciled and settled, with interest at proper rates and the transfer-pricing and tax implications handled. IHC gives you the internal bank; it also gives you an internal book to run with real rigour.

What usually goes wrong

• Underestimating intercompany accounting. The internal accounts generate intercompany balances that must be tracked, reconciled and settled — and remember FI receives summarised current-account movement, not a document per internal payment. Design this up front, not after go-live.
• Bank areas designed as an afterthought. One company code per bank area is a hard constraint, and the bank-area count is your cash-centre count. Getting this wrong is a re-implementation, not a config change.
• Treating it as pure technology. IHC is an operating-model and accounting change as much as a system one; configure the module and neglect the process, and adoption and reconciliation suffer.
• Confusing IHC, the payment factory and In-House Banking. Three different things, two of which share a name. Scoping one when you needed another is how the centralization ends up half-built.
• Ignoring the tax/transfer-pricing angle. Intercompany lending and on-behalf-of activity carry real tax and transfer-pricing implications that treasury can't wave away.

What I left out, on purpose

• IHC transaction codes. This is the deliberate gap, and the honest one. SAP's In-House Cash documentation is written around menu paths and Customizing nodes; I could not verify a set of IHC GUI transaction codes in SAP Help, so none are printed here. The codes circulating on dump sites may well be right — but "may well be" is not this site's standard. Where you do need archiving administration, the objects above are called through SARA, and AOBJ shows which archiving classes an object triggers; both are documented.
• The BCA current-account tables. In-House Cash's payment-order tables are documented (above); the Bank Customer Accounts persistence beneath the current accounts is not, in anything I could verify. The archiving objects are the sanctioned handle on that data instead.
• In-House Banking Fiori apps without a printed app ID. The In-House Banking Dashboard is documented as an app but its page carries no app ID, so it appears here without one rather than with a guessed one.
• Release and edition availability. Which of classic IHC and In-House Banking you actually get depends on your release and deployment model, and stating a version from memory is how references go stale. Check your release notes.

Use IHC as the internal-banking backbone of a centralized SAP treasury — paired with a payment factory for external payments — and design the intercompany accounting as carefully as the cash. It's a powerful piece of the centralization story, and, like every part of that story, it's only as clean as the intercompany plumbing beneath it.

See also what is an in-house bank and what is a payment factory.