SAP TRM Product Types and Transaction Types, Explained

Every deal in SAP Treasury is classified before it is captured, and the classification has three layers: the product category (fixed by SAP — 550 Interest Rate Instrument, 600 FX Transaction, 040 Bond), the product type (yours to configure — 51A Fixed-Term Deposit, 60A Foreign Exchange), and the transaction type (what you're doing under that product type — 100 Investment, 200 Borrowing, 101 Spot, 102 Forward). Underneath sit flow types and update types, classifying every movement the deal generates. That's the whole model, and this page walks down it layer by layer — with the delivered codes checked against SAP's documentation, because this is a corner of TRM where forum lore and real configuration have drifted apart.

Why it's worth a page of its own: the classification is not labeling. It's the key everything downstream reads. Which activity chain the deal walks through, which flows it may carry, how its position updates, how it posts, whether it can be excluded from a valuation area, even which planning level it lands on in Cash Management — all of it is configured against product category, product type and transaction type. When the Transaction Manager takes a deal from capture to accounting, this classification is the thread it follows. And it's chosen in the first seconds of the deal's life: before you can enter a single amount in FTR_CREATE, you've picked a product type and a transaction type — SAP's documentation lists defined product types, transaction types, flow types and condition types as prerequisites for creating financial transactions at all.

The three layers at a glance

The textbook mnemonic: SAP owns the nouns, you own the vocabulary. The categories are the fixed set of things a treasury system can conceptually hold; the product types are your names for the ones you actually trade; the transaction types are the verbs — invest, borrow, buy, sell, spot, forward — allowed on each.

Product categories: SAP's layer, and it's numbered

SAP's definition is compact: the product category is "a predetermined classification of the financial products in the transaction management" — an internal key, predefined in the system, and "the product category controls the processing of the financial instruments created based on the product types." You assign each product type to exactly one category; the categories themselves are not yours to extend.

They come as numbered families, and the numbering is worth learning because you'll meet it in configuration and in the database tables alike. From SAP's S/4HANA documentation, the available categories include:

• Money market — 530 Commercial Paper, 540 Cash Flow Transaction, 550 Interest Rate Instrument, 560 Facility, 580 Current Account-Style Instrument
• Foreign exchange — 600 FX Transaction (with 760 OTC Options listed for the FX area too)
• Securities — 010 Stock, 020 Fund, 030 Subscription Right, 040 Bond, 042 Installment Bond, 060 Bond with Warrant, 070 Convertible Bond, 111–114 warrant categories, 160 Shareholding
• OTC derivatives — 610 Cap and Floor, 620 Swap, 630 Forward Rate Agreement, 640 Total Return Swap, 740 Forward Securities Transaction, 760 OTC Option, 770 Securities Lending, 780 Forward, 790 Forward Loan
• Listed derivatives — 700 Future, 750 Listed Options
• Trade finance — 850 Letter of Credit, 860 Bank Guarantee
• Special — 690 External Account, plus 990 Exposure and 991 Exposure Item for Exposure Management and hedge accounting

One reality check that surprised me while verifying: the list is edition-dependent. SAP's S/4HANA Cloud Public Edition documentation publishes a visibly shorter set — the securities family stops at 160 Shareholding with no warrant or convertible categories, and the derivatives family is essentially 620 Swap and 760 OTC Options. Same concept, smaller menu. If your instrument isn't in your edition's category list, no amount of configuration will book it, which makes this one of the first pages to check in a deployment-model decision.

Above the categories sits one more key you'll trip over in flow-type configuration: the contract type, an internal key for the application areas themselves — 2 securities, 4 foreign exchange, 5 money market, 6 derivatives, T trade finance, plus E for exposure positions and X for external accounts. File it away; it comes back in a moment.

Product types: your layer, with SAP's examples in the box

SAP's own definition, from the current Cloud documentation: "Product types are used to further segment financial instruments assigned to a product category according to company-specific requirements. Each product type is assigned to exactly one product category." The product type is where you hang the structural characteristics — which condition types and flow types the instrument carries — and control parameters for transaction management, "such as processing categories and status transfers." The on-premise terms documentation gives the canonical example of what "segment to company requirements" means: splitting stock into domestic stock and foreign stock.

You don't start from nothing. The ERP documentation says it plainly — "Alternatively, you can use the product types provided by SAP" — and the S/4HANA Cloud documentation publishes the delivered list outright: 33 predefined product types. A representative cut, verbatim from that table:

Read the codes against the categories and the naming convention shows itself: the delivered product type usually takes the leading digits of its category — 53A under 530, 60A under 600, 62A under 620, 04A under 040. Usually, not always: 51A Fixed-Term Deposit and 52B Deposit at Notice both sit under category 550 Interest Rate Instrument in the current table, a fossil of instrument history that's worth knowing precisely because it breaks the pattern people assume. Two other delivered families worth noting from the same page: the intercompany-flavored types with an "- INT" suffix (60I, 60J, 55I, 58I), and the special-purpose ones — product types for exposures under category 990/991, and 20A Bank Account under category 200 for Bank Account Management, which is how even bank accounts get positions in the treasury machinery.

The delivered examples above are the Cloud edition's published list. On-premise systems ship standard-delivery product types the same way, but I couldn't find a page in the current on-premise documentation that publishes the full delivered table — so what's printed here is what's verifiable, and your system's own configuration is the authority for the rest.

Transaction types: what you're allowed to do with it

A product type alone doesn't make a deal — SAP's FX configuration documentation ends its product-type definition with exactly that: "The financial transaction is finally set up by combining the product type with a transaction type."

The definition stack has a subtlety here that the forum explanations flatten. There is a predefined layer even inside this: the transaction category — fixed in the system per product category, e.g. fixed-term deposit investment versus fixed-term deposit borrowing — and then the transaction type, which "determines how a financial transaction is processed" and can "group transaction categories according to company-specific requirements." In other words: SAP predefines that an interest rate instrument can be invested or borrowed; you define the transaction types that expose those directions to your dealers. The configuration activities say it directly: "you define your transaction types and assign them to your product types," and specify with them the administrative functions and processes each combination supports.

The delivered examples SAP names, again verbatim from its intercompany-trading documentation:

• 60I Foreign Exchange - INT with transaction types 101 Spot Transaction and 102 Forward Transaction — also used, as 101/102, for FX swaps
• 60J Non-Deliverable Forward - INT with transaction type 110 Non-Deliverable Forward
• 55I Interest Rate Instrument - INT with transaction types 100 Investment / 200 Borrowing
• 58I Current Account-Style Instrument - INT with transaction type 300 Investment/Borrowing

That's the shape to remember even outside the intercompany context: FX transaction types distinguish spot from forward; money market transaction types distinguish investment from borrowing; and where a single position can run both ways, one combined type (300) covers it.

One more thing rides on the transaction type, and it's the consequential one: the processing category. SAP's terms documentation puts it in one sentence — "the processing category assigned in the transaction type definition decides on the activity chain of a financial transaction." Whether a deal goes through order and contract stages, whether it needs settlement — that's the activity chain, and it's fixed the moment the transaction type is chosen. The same field even polices intercompany mirroring: SAP requires that a mirror transaction's transaction type have "the same processing category" as the original. When back-office people argue about why one deal type demands settlement and another doesn't, this is the field they're arguing about, whether they know it or not.

The layer below: flow types and update types, briefly

Deals generate flows — "flows document changes to the transactions," carrying date, amount and calculation data — and the classification continues down into them. Two type systems, one gotcha each:

• Flow types classify a transaction's flows: each flow has exactly one, defined in configuration along with characteristics like posting relevance and inclusion in cash management. The gotcha, straight from SAP's documentation: a flow type is only unique per contract type — "flow type 1000 for contract type 2 is different from flow type 1000 for contract type 4." The same four digits mean different things in securities and FX. If you're comparing flow-type configuration across product areas, you are not comparing like with like. Assignment is per deal classification: to the transaction types of your product types you assign "all flow types necessary for a complete portrayal of the financial instruments" — SAP's phrase, and a good bar for completeness testing.
• Update types classify the flows that update positions in parallel position management — and their definition, unlike flow types, "is not limited to the contract type." They're the currency of the position management and valuation layer: flow types map to update types in configuration, update types get flagged as posting-relevant and payment-relevant, and position updates are assigned per product type and transaction type — an update type for open and close transactions for each combination. SAP's example update type is worth quoting for flavor: V152, "one-step rate/price valuation: write-up foreign exchange." Where update types go from there — posting specifications, account symbols, G/L accounts — is the posting architecture's story, not this page's.

What the classification drives downstream

Everything. But concretely, these are configuration activities SAP documents that key on the classification you chose at capture:

• The activity chain — via the processing category on the transaction type, as above.
• Position updates — update types for open/close assigned per product type and transaction type.
• Default valuation class — a general valuation class assigned "for each combination of company code, product type, and transaction type," defaulted onto the deal at entry.
• Valuation-area scope and posting scope — product groups, categories and types can be excluded from parallel valuation areas, and product types excluded from the Financial Accounting update per valuation area and accounting code.
• Cash Management integration — planning levels assigned per company code, product type and activity, or derived by substitution rules.
• Credit risk — limit product groups "group different product and transaction types" for limit utilization, and product categories drive the default risk data of financial objects.

That list is why I called the classification the backbone: change a product type after go-live and you're not renaming a label, you're re-keying half a dozen downstream determinations — and the deals already captured keep the old key, sitting in VTBFHA with their product type and transaction type stamped on them. The practical discipline that follows: resist product-type proliferation. Every new product type is a new row in every one of those determination tables, times valuation areas, times company codes. Add one when instruments genuinely process or post differently — that's what the layer is for — not to give each desk its own label; reporting dimensions are cheaper everywhere else.

The standing caveat, as always in this SAP treasury guide: the concepts here are stable, but the delivered lists are not — categories and predefined types differ between on-premise releases and the cloud editions, and the tables above quote specific documentation versions. Before you build a design on a delivered code, open your system's own configuration and check it's actually in the box.

See also SAP Transaction Manager: deals and instruments and SAP treasury transaction codes.