TCURR table — TCURR Exchange Rate Table

Each row in TCURR is one exchange rate: for a given exchange rate type, converting from one currency to another, valid from a specific date until superseded by the next entry for the same type and currency pair. SAP does not store a rate per day; it stores the date from which a rate becomes effective, and the system searches backward from the requested date for the most recent entry that is not later than it. Rates are maintained for both direct and indirect quotation depending on configuration, and the ratio fields allow rates to be expressed per unit or per hundred, per thousand, and so on for currencies with large denomination differences. The table is client-independent-looking in structure but carries a client field like all standard tables, and it is small enough in most systems to be read in full without performance concern.

TCURR is small relative to most FI tables, typically a few thousand to a few hundred thousand rows depending on how many currency pairs and rate types are maintained and how far back history goes, so a full table scan is rarely a performance problem. The selective fields are KURST, FCURR, TCURR, and GDATU. Never search for an exact GDATU match when trying to reproduce what a program used; the correct lookup is the maximum GDATU that is less than or equal to the date in question, for the given type and currency pair. The client field is present but irrelevant to selectivity since almost every system runs a single relevant client for FI data.

Symptom: a foreign currency valuation run produced a translated amount that looks wrong for a specific vendor invoice. Take the exchange rate type from the valuation method, the currency pair from the invoice document and company code currency, and the valuation key date. Select TCURR where KURST, FCURR, TCURR match and GDATU is less than or equal to the valuation date, ordered descending by GDATU, and take the first row. That UKURS, adjusted by FFACT and TFACT, is the rate the run should have used. If it does not match the rate embedded in the posting, the discrepancy is in configuration or timing, not in TCURR itself.

TCURR is unchanged in S/4HANA; it remains a standard client-dependent transparent table and continues to be the source table for currency translation across FI, CO, and the universal journal. No CDS compatibility view replacement applies here since the table was never restructured. Programs and CDS views that need exchange rates still read TCURR through the same date-backward lookup logic, now often wrapped in AMDP or CDS-based currency conversion functions rather than custom ABAP, but the underlying table and its fields are identical to ECC.

Exchange rate maintenance is normally a treasury or FI master data task, often automated by a feed from a market data provider rather than manual entry. When a translated amount is disputed, the first question for FI is which rate type and date the process used; the answer to whether that rate is correctly maintained in TCURR belongs to whoever owns the rate feed, not to the module consultant running the valuation.

TCURV holds the definitions and validity rules for exchange rate types referenced by KURST. Currency translation feeds into BKPF and BSEG at document posting and into ACDOCA as the stored multi-currency amounts on the universal journal. Rates are maintained through standard exchange rate maintenance transactions or loaded via batch interface from external rate providers; valuation runs and consolidation reads pull from TCURR but never write back to it.