SAP Treasury Tables: Where Deals, Flows and Positions Live

Every SAP Treasury deal you capture ends up as rows in a handful of tables: the deal in VTBFHA, its flows in VTBFHAPO, its conditions in VTBFINKO — and from there the trail runs through the Treasury subledger into BKPF, BSEG and ACDOCA on the FI side, with FQM_FLOW and FEBKO/FEBEP carrying the cash and bank-statement view. This page is the map of those tables. It exists for the same reason as its sibling, the treasury transaction codes reference: search for "SAP treasury tables" and you get scraped dictionary dumps listing hundreds of names with no indication which ones a treasury system actually writes to — or whether they exist at all. So, same method: every table below is verified against SAP's own documentation, and anything I couldn't verify there didn't make the page. That cuts the list down, and the cuts are documented at the end, because knowing what's not verifiable is half the value.

One scope note first: table names are an on-premise and private-edition concern. That's where you have SE16N, query tools and interfaces reading the database. SAP S/4HANA Cloud Public Edition gives you released APIs and CDS views instead of table access, so if that's your target, read this page as background, not as a query plan.

The deal: the VTBFHA family

The best evidence that VTBFHA is the deal table is how consistently SAP's own S/4HANA migration objects point at it: fixed-term deposits, deposits at notice, FX spot/forward contracts, FX swaps, FX options, interest rate swaps, interest rate instruments, commercial paper, stocks, bonds, investment certificates, letters of credit and bank guarantees all "automatically select" their contract data "from the VTBFHA table". One table, every product type — which is exactly why FTR_CREATE can capture a money market deal and an FX forward through the same transaction. Changes to a deal are tracked under a change document object that SAP also names VTBFHA.

The satellites divide the deal up the way the Transaction Manager thinks about it. VTBFHAZU carries the data of each activity — SAP's trade repository documentation reads the contract date from VTBFHAZU-DVTRAB, and its FX documentation reads the transaction exchange rate (KKURS) and swap rate (KSWAP) from the same table. VTBFHAPO carries the flows; the migration object for main flows selects from it, and SAP's data-protection documentation looks for the payer and paying bank there, which tells you payment-relevant detail sits at flow level. VTBFINKO holds the conditions, VTBZV the payment details, VTBPA the partner assignments. When you trace a deal in SE16N, that's the read order: VTBFHA for the deal, VTBFHAZU for what happened to it, VTBFHAPO for what it pays, VTBFINKO for why it pays that.

For securities, one master-data table belongs in this group: VWPANLA, the class data of the security. SAP's extraction documentation selects ID numbers from it, and the data-protection documentation locates the issuer there. It's the table behind the FWZZ class master, the same way BP sits behind the counterparty on the deal.

Positions: where the dump sites bluff

Here's the section that surprised me while verifying: SAP Help does not name the physical tables of the Treasury position subledger. The dump sites list names for them anyway. I couldn't verify those names in any SAP documentation, so they're not here — and I'd treat any list that includes them as unreviewed until you've checked SE11 yourself.

What SAP documents instead are the access paths, and honestly they're what you should be using anyway:

• The position reports — TPM12 for position values, TPM13 for position flows, TPM20 for the posting journal. The working trio from the transaction codes reference.
• Logical databases — FTI_TR_POSITIONS ("evaluate positions in the Transaction Manager for a given key date") and FTI_TR_PERIODS for period evaluations, both documented in the TRM information system. If you're building a custom position report, this is SAP's sanctioned read path.
• CDS extraction views — in S/4HANA Cloud, SAP documents treasury-ledger transaction flow views for data extraction, which is the direction position reporting is moving generally.
• Archiving object TRTM_TPM — positions are archived in "position groups", and SAP's archiving documentation describes the grouping rules in detail without ever naming the underlying tables.

The one treasury-ledger table SAP does name is TRLT_INIT_VAL_SE, and only in a narrow role: when you initialize a new parallel valuation area, the position determined from the leading valuation area is saved there as the target structure for building the new one. Real table, documented purpose, and almost certainly not what you were looking for when you searched "SAP treasury position table". What positions mean and how valuation writes them matters more than their physical storage — which is presumably the point of SAP not documenting it.

The FI border: BKPF, BSEG, ACDOCA

Treasury postings become accounting documents, and SAP's documentation is plain about what that means at the database level: BKPF is the accounting document header, BSEG the accounting document segment — the line items. The BKPF/BSEG join has its own article here, including the four-field key that people get wrong and the SHKZG sign handling; tracing what TBB1 posted for a specific deal lands you exactly on that join.

Two qualifications from the S/4HANA side. First, ACDOCA: SAP's documentation calls the universal journal table "the single source of truth for all processes and reports in accounting" — so balance and reporting queries belong on ACDOCA, and the BKPF/BSEG join stays for document-level detail. Second, the classic open/cleared-item index tables — BSIS/BSAS for G/L accounts, BSID/BSAD for customers, BSIK/BSAK for vendors, the tables behind the FBL3N/FBL5N/FBL1N line item lists in SAP's own support documentation — are an ECC-era pattern; on S/4HANA the universal journal carries that load. The treasury-side view of the same postings is TPM20, and the posting architecture article explains how the subledger and the general ledger relate.

Cash management: FQM_FLOW ate the old tables

S/4HANA cash management reads one table where classic Cash Management read several. SAP's documentation states it directly: "SAP S/4HANA Finance for cash management consumes data from the One Exposure from Operations table (database table FQM_FLOW)" — and One Exposure aggregates flows from FI, TRM, Loans Management and integrated remote systems into that single store. This site has a full article on One Exposure and FQM_FLOW, and a second on reconciling it when the numbers look wrong, so here I'll only place the table among its neighbors:

• FDES, the classic memo record table, is documented as replaced: memo records "are no longer stored in table FDES", and SAP ships the migration report FCLM_MIGR_FDES2FQM to move existing ones into FQM_FLOW. If your interface still writes FDES on S/4HANA, this is the documentation to wave at its owner.
• FDSB, the classic Cash Management summary balance table, survives long enough that SAP documents a reconciliation view comparing "data stored in table FDSB of Classic Cash Management" against FQM_FLOW — a sentence that quietly confirms both tables' roles.
• PAYRQ, the payment request table, holds the settlement-side objects treasury generates for F111; SAP documents it as the segment of archiving object FI_PAYRQ, and One Exposure carries forecasted flows from payment requests under a certainty level named after it.

Bank statements: FEBKO, FEBEP and the ring around them

For once, SAP publishes exactly the table you'd want: a technical FAQ for SAP Cash Application that lists the bank statement tables by name and purpose.

The shape to remember: one FEBKO entry per imported statement, one FEBEP entry per transaction line, FEBRE hanging off the item with the unstructured note-to-payee text that your search strings parse. When the electronic bank statement run posts or fails to post, the evidence is in FEBEP's posting fields — SAP's own troubleshooting content walks through FEBEP fields like BELNR and INTAG when a statement misbehaves. And a nicely current detail: SAP Cash Application's proposal status lives in FEBEP-ML_STATUS, so even the machine-learning layer reports into the same thirty-year-old table family.

Banks, accounts and BAM

The division of labor: BNKA knows the bank exists, T012/T012K know your company banks there, and FCLM_BAM_AMD is the Bank Account Management layer S/4HANA put on top — the table you extend (SAP documents appending structure CI_AMD_EXT to it for custom fields) and the table that's gaining authority over time: a recent release note makes FCLM_BAM_AMD-CONTROL_KEY "the single source of control keys", removing the field from the house bank account UI. That's the migration from T012K-centric to BAM-centric bank account data happening one field at a time, in public.

Payments and rates

Two FI table groups that every treasury investigation eventually touches. The payment run — F110 or treasury's F111 — creates entries in REGUH (payment data per payee) and REGUP (the paid items); SAP's support documentation states the pair is written when the run executes, and the S/4HANA documentation still carries the classic guide to displaying REGUH/REGUD/REGUP fields for payment forms. When a settlement leaves Bank Communication Management and someone asks "what exactly went into that batch", REGUH/REGUP is the answer at table level.

And TCURR, the exchange rate table behind OB08 — documented by SAP with its siblings TCURV (rate types), TCURF (conversion factors) and TCURX (decimal places). Treasury valuation reads it constantly, which is why it appears in the market data article and in every "why is TPM1 producing nonsense" call.

What I left out, on purpose

The exclusions are the part the dump sites can't give you, so here they are explicitly:

• The Treasury position subledger tables. Not named in SAP Help, as covered above. The names circulating on dump sites for the position and flow layer may even be right — but I couldn't verify them, so they're out. Verified access paths (TPM12/TPM13, the FTI_TR_* logical databases, TRTM_TPM) are in.
• Hedge accounting tables. SAP documents hedge management functionally — hedging relationships, designation, TPM100 and its siblings — without naming the underlying tables anywhere I could verify. Same rule, same outcome.
• The Analyzer tables, mostly. SAP's data-protection documentation names a set of Risk Management tables — JBRDBKO, JBRSVKO, VTBLS, KLNT01, KLMAXLIMIT among them — but only as a list of places business partner data appears, with no statement of what each table does. Names verified, purposes not documented, so they don't get rows in the tables above.
• Loans Management (FS-CML) and In-House Cash. Different components with their own table families; mixing them in is how the 400-row dumps became unusable.

The standing caveat from the transaction codes post applies double here: releases move things. FDES lost its job to FQM_FLOW, T012K is losing fields to FCLM_BAM_AMD, and BSEG-first reporting gave way to ACDOCA. If you're carrying interfaces that read these tables into an S/4HANA migration, the ECC to S/4HANA article covers which of those reads survive — because a table still existing is not the same as it still being the right place to look.

See also Joining BKPF and BSEG without losing your mind and SAP Treasury Transaction Codes: The Ones That Matter.