R2R ยท DEEP TECHNICAL REFERENCE
R2R Technical Configuration Reference
Use these 57 configuration checkpoints to locate technical settings after the R2R close spine is understood. This reference supports the workbench; it is not the normal learning path.
CURATED SOURCE REGISTER
R2R implementation register
A curated, release-labelled register derived from the supplied FI/CO implementation inventory. Use it to locate the setting, identify its ownership and transport boundary, and define proof. It is a planning aid, not a substitute for the IMG and activated scope in the target system.
Core
Part of the minimum S/4HANA 2025 R2R accounting spine.
Confirm
Relevant only when the approved design requires it; confirm the target-release access path and behavior.
Optional / localized
Country, product, or scenario-specific; keep outside the minimum spine until approved.
Legacy
ECC, classic, compatibility, or deprecated content; retain only for transition analysis.
57 of 57 entries shown
Transport rule: Move only approved project-owned entries and their known dependencies. Customizing, master data, number-range intervals, exchange rates, operational jobs, workflow content, and migration data do not share one deployment mechanism.
IMPLEMENTATION REGISTER
Establish legal and fiscal scope
7 of 7 entries shown
| Status | Scope / area | Task, dependency, and proof | Access / objects | |
|---|---|---|---|---|
| Core | ClientFinance organization | Create the operational chart of accounts and define the G/L account-number lengthDepends on: Approved account architecture and group-account mappingProof: Display the chart definition and create or validate a governed test account. | OB13T004 |
Customizing |
| Core | Company codeFinance organization | Assign the chart of accounts to the company codeDepends on: Company code and chart of accounts existProof: Company-code parameters show the intended operational chart. | OB62T001 / T004 |
Customizing |
| Core | Client / company codeFiscal calendar | Define and assign the fiscal-year variantDepends on: Statutory calendar and special-period policyProof: Posting dates derive the expected normal and special periods. | OB29 / OB37T009 / T009B / T001 |
Customizing |
| Core | Client / company codePeriod control | Define and assign the posting-period variantDepends on: Company code and period-control ownershipProof: The company code resolves to the approved posting-period variant. | OBBO / OBBPT010O / T001 |
Customizing |
| Core | Company codePeriod control | Maintain controlled posting-period intervalsDepends on: Posting-period variant, account types, authorization groups, close calendarProof: Positive and negative postings prove open, closed, and adjustment-period behavior. | OB52T001B |
Operational control data; handle through cutover and restricted access |
| Core | Controlling areaManagement accounting | Define the controlling area and assign the company codeDepends on: Compatible chart, fiscal year, and currency designProof: A journal accepts the intended cost object and rejects an invalid assignment. | OKKP / OX19TKA01 / TKA02 |
Customizing |
| Confirm | Client / company codeReporting dimensions | Define segments and govern profit-center assignmentsDepends on: Segment-reporting policy and responsibility modelProof: Journal lines derive valid profit center and segment values and report correctly. | SPRO / Manage Profit Centers / KE51 where availableFAGL_SEGM / CEPC / CEPC_BUKRS |
Customizing for design; master data for profit centers |
IMPLEMENTATION REGISTER
Design ledgers, principles, and currencies
7 of 7 entries shown
| Status | Scope / area | Task, dependency, and proof | Access / objects | |
|---|---|---|---|---|
| Core | Client / company codeLedgers and currencies | Define leading-ledger and company-code currency settingsDepends on: Accounting principles, local and group reporting currenciesProof: A posting creates the expected ledger and currency-type values in ACDOCA. | FINSC_LEDGERFINSC_LEDGER / FINSC_LD_CMP |
Foundational Customizing; architecture approval required |
| Confirm | Ledger / company codeParallel accounting | Define and assign non-leading ledgers and ledger groupsDepends on: Approved parallel-accounting designProof: Ledger-specific test postings and reports isolate the intended accounting principle. | FINSC_LEDGERFINSC_LEDGER / FINSC_LD_CMP |
Foundational Customizing |
| Confirm | LedgerExtension ledger | Define an extension ledger only for an approved delta-posting use caseDepends on: Underlying ledger, accounting use case, reporting and reversal designProof: Inherited and delta values reconcile to the base ledger without double counting. | FINSC_LEDGERFINSC_LEDGER |
Customizing |
| Core | ClientExchange rates | Define exchange-rate types and translation ratiosDepends on: Treasury rate policy and currency-pair conventionsProof: A controlled translation uses the approved rate type and ratio. | OB07 / OBBSTCURV / TCURF |
Customizing |
| Core | ClientExchange rates | Maintain governed exchange-rate valuesDepends on: Approved source, effective date, quotation and workflowProof: Rate display and a valuation test agree to the approved source. | OB08 / TCURMNTTCURR |
Operational reference data; govern separately from design transports |
| Core | ClientCurrency precision | Verify currency decimal-place settings before transactional useDepends on: ISO/local currency definition and conversion assessmentProof: Document entry, storage, and reporting preserve the intended precision. | OY04TCURX |
Foundational Customizing; high-risk after postings |
| Legacy | Company codeLedger configuration | Treat direct maintenance of classic ledger views as transition evidence onlyDepends on: Source-system assessmentProof: Target design is recreated and proven in FINSC_LEDGER rather than copied blindly. | SM30 views for T881 / T882GT881 / T882G |
Legacy release-dependent Customizing |
IMPLEMENTATION REGISTER
Control accounts and journal entries
8 of 8 entries shown
| Status | Scope / area | Task, dependency, and proof | Access / objects | |
|---|---|---|---|---|
| Core | Chart / company codeG/L master | Migrate and extend governed G/L accountsDepends on: Chart, account group, field status, tax and open-item policyProof: The account posts only with the intended field, currency, tax, and open-item behavior. | Migration Cockpit / approved master-data loadSKA1 / SKB1 |
Master data; deploy through the approved master-data process |
| Core | ChartG/L master controls | Define account groups and G/L master field statusDepends on: Account architecture and master-data governanceProof: Create/change tests show mandatory, optional, suppressed, and display-only fields. | OBD4T077S |
Customizing |
| Core | ClientJournal controls | Define document types and number-range assignmentsDepends on: Journal taxonomy, ledger scope, reversal and audit policyProof: Posted documents use the expected type, interval, year behavior, and audit trail. | OBA7 / FBN1T003 / NRIV |
Document-type Customizing; number-range intervals need separate handling |
| Core | ClientJournal controls | Review posting keys and field-status interactionDepends on: Account type, debit/credit and field-status designProof: Positive and negative journal tests demonstrate the intended field controls. | OB41TBSL |
Customizing; change only with explicit design need |
| Core | Company code / employee groupTolerances | Define posting and clearing tolerancesDepends on: Delegation of authority and difference policyProof: Boundary-value tests accept permitted differences and reject amounts above authority. | OBA4 / OBA3 / OBA0T043S / T043G / T043T |
Customizing |
| Core | Client / company codeValidation and substitution | Define and activate journal validations and substitutionsDepends on: Control requirement, call-up point, message and exception designProof: Positive, negative, reversal, interface, and background-posting tests behave consistently. | GGB0 / GGB1 / OB28 / OBBHGenerated rules / T001D / T001Q |
Workbench and Customizing content; verify generated objects and activation |
| Confirm | Client / company codeDocument splitting | Configure document splitting only when balanced reporting dimensions require itDepends on: Segment/profit-center balance-sheet policy and zero-balance designProof: Simulation and live tests produce balanced dimensions without unexplained clearing lines. | SPRO document-splitting activities / FINS_SIS_SIM_SPLT8G17 / T8G20 / FAGL_SPLIT_FIELD |
Cross-dependent Customizing; sequence and simulate before activation |
| Legacy | Controlling areaCost elements | Treat KA01/KA06 cost-element creation as legacy for S/4HANA primary accountsDepends on: ECC transition assessmentProof: S/4HANA G/L account category supplies the required cost-element behavior. | KA01 / KA06CSKA / CSKB |
Legacy master-data process |
IMPLEMENTATION REGISTER
Connect source processes and subledgers
7 of 7 entries shown
| Status | Scope / area | Task, dependency, and proof | Access / objects | |
|---|---|---|---|---|
| Core | Sales organization / chartSD integration | Define SD revenue and related account determinationDepends on: Chart, account keys, customer/material classifications, tax and pricing designProof: Billing posts to the expected revenue, discount, tax and reconciliation accounts. | VKOACondition tables / KONP / resulting ACDOCA |
Customizing |
| Core | Valuation area / chartMM integration | Define inventory and GR/IR account determinationDepends on: Valuation grouping, valuation class, transaction and account modifierProof: Goods receipt and invoice receipt reconcile inventory, GR/IR, liability and price differences. | OBYCT030 keys BSX / WRX |
Customizing |
| Core | Valuation area / chartMM integration | Define consumption, physical-inventory and price-difference accountsDepends on: Movement types, modifiers, valuation classes and currency designProof: Controlled movements post to the expected expense, variance and exchange-difference accounts. | OBYCT030 keys GBB / PRD / KDM |
Customizing |
| Core | Client / Business PartnerSubledger master data | Align Business Partner roles and number ranges with customer/supplier integrationDepends on: Customer/supplier account groups, number strategy and synchronization directionProof: A Business Partner creates or synchronizes the intended customer/supplier roles without number collision. | BP / BUCF / CVI CustomizingTB003 / TB001 / CVI mapping views / BUT000 |
Customizing for roles and mappings; Business Partners are master data |
| Core | Customer / supplier account groupReconciliation accounts | Govern reconciliation-account determination and sensitive master fieldsDepends on: Account groups, reconciliation-account and four-eyes policyProof: Subledger postings update the correct reconciliation account and direct G/L posting is blocked. | BP / account-group and sensitive-field CustomizingKNB1 / LFB1 / reconciliation G/L |
Customizing plus master-data governance |
| Confirm | Client / company codeCO integration | Confirm CO document-type and ledger mapping for integrated postingsDepends on: Ledger, controlling version and document-type designProof: Primary and secondary cost postings reach the expected ledger, account and dimensions. | FINSC_VERSN_LD / FINS_CO_DOCT_CC views where applicableFINSC_VERSN_LD / FINS_CO_DOCT_CC |
Release-sensitive Customizing |
| Legacy | Company code / credit control areaCredit management | Keep classic FI credit-management settings outside the R2R S/4HANA spineDepends on: Decision between classic credit management and SAP Credit ManagementProof: Approved target credit solution owns limits and exposure; no hybrid control is assumed. | FD32 / classic OB45 and SD credit settingsKNKK / S066 |
ECC transition content |
IMPLEMENTATION REGISTER
Configure open items, payments, and bank statements
7 of 7 entries shown
| Status | Scope / area | Task, dependency, and proof | Access / objects | |
|---|---|---|---|---|
| Core | Chart / company codeAutomatic clearing | Define automatic-clearing criteria and difference accountsDepends on: Open-item accounts, matching fields, tolerances and reason-code policyProof: A clearing run matches only eligible items and posts approved differences transparently. | OB74 / OBXZ / OBXLV_TF123 / T030 |
Customizing |
| Core | Company codePayment differences | Define reason codes for payment differencesDepends on: Residual-item, partial-payment, charge and write-off policyProof: Incoming-payment tests create the expected residual item or difference posting. | OBBET053R |
Customizing |
| Core | Country / company codeAutomatic payments | Configure payment methods, paying company codes and bank selectionDepends on: House banks, payment policy, supplier data, formats, approvals and securityProof: F110 proposal selects eligible items and bank accounts; blocked or ineligible items remain excluded. | FBZPT042 / T042A / T042B / T042E / T042Z |
Customizing |
| Core | Company codeHouse banks | Create and govern house banks and bank accountsDepends on: Bank keys, account IDs, G/L accounts, signatories and workflowProof: Payment and statement scenarios resolve the correct bank account and clearing path. | Manage Banks / Manage Bank Accounts; FI12 only where applicableBank and bank-account master data / T012 compatibility objects |
Master or application data with product-specific deployment |
| Core | Company codeElectronic bank statement | Define account symbols, posting rules and external-transaction mappingDepends on: Bank format, transaction codes, G/L design and clearing referencesProof: A representative statement imports, posts and clears with traceable exceptions. | OT83T033I / T033G / T033F / T028G |
Customizing |
| Confirm | Company codePayment media | Configure payment-medium formats and variants for the approved bank channelDepends on: Bank specification, security, approvals and file-transfer ownershipProof: A non-production payment file validates to the bank specification and ties to the payment run. | OBPM1 / OBPM4 / Manage Payment FormatsPayment-medium format and variant objects |
Customizing plus governed variants; external connectivity is separate |
| Confirm | Company code / workflowBank communication | Implement BCM, Multi-Bank Connectivity, or payment approval only when separately approvedDepends on: License, bank onboarding, security, retention and operating modelProof: Maker-checker, rejection, resubmission and audit evidence work without live transmission during testing. | Product-specific Fiori apps and workflowProduct-specific |
Product, workflow, role and connector boundary |
IMPLEMENTATION REGISTER
Configure Asset Accounting and depreciation
6 of 6 entries shown
| Status | Scope / area | Task, dependency, and proof | Access / objects | |
|---|---|---|---|---|
| Core | Chart / company codeAsset Accounting | Define chart of depreciation and assign it to the company codeDepends on: Valuation principles, ledgers, currencies and fiscal yearProof: Asset values update the intended depreciation areas and ledger groups. | SPRO Asset AccountingT093 / T093B and current Asset Accounting objects |
Foundational Customizing |
| Core | Chart of depreciationDepreciation areas | Define depreciation areas, posting behavior and ledger-group assignmentDepends on: Book, tax and group valuation designProof: Acquisition and depreciation post only to the intended accounting principles. | SPRO Asset AccountingT093A and current ledger-assignment objects |
Customizing |
| Core | Chart / asset classAsset master | Define asset classes, number ranges and screen layoutDepends on: Asset taxonomy, capitalization policy and ownershipProof: Asset creation enforces the correct account determination and required master fields. | OAOA / AS08 / SPROANKA / NRIV / screen-layout objects |
Customizing; asset records are master data |
| Core | Chart of accountsAsset integration | Define Asset Accounting account determinationDepends on: Asset classes, transaction types, depreciation areas and G/L accountsProof: Acquisition, retirement, transfer and depreciation hit the expected balance-sheet and P&L accounts. | AO90T095 / T095B and resulting ACDOCA |
Customizing |
| Core | Company codeDepreciation run | Schedule and prove depreciation postingDepends on: Open periods, complete asset values and depreciation keysProof: Planned depreciation, posted journal values and Asset Accounting reports reconcile. | AFAB / Schedule Asset Accounting JobsAsset values / ACDOCA / job log |
Run parameters and job instances are operational data |
| Confirm | Company codeLegacy asset migration | Load legacy asset values only through a reconciled migration designDepends on: Transfer date, takeover values, accumulated depreciation and reconciliationProof: Asset history sheet, G/L control accounts and approved source totals agree. | Migration Cockpit / approved Asset Accounting migration toolsAsset master and value objects / ACDOCA |
Migration data, not ordinary Customizing |
IMPLEMENTATION REGISTER
Configure accruals, valuation, allocation, and clearing
7 of 7 entries shown
| Status | Scope / area | Task, dependency, and proof | Access / objects | |
|---|---|---|---|---|
| Core | Client / valuation areaForeign-currency valuation | Define valuation methods, areas and accounting-principle assignmentDepends on: Ledger groups, accounting principles, rate types and valuation policyProof: A controlled FCV run uses the intended method, key date, rate and ledger scope. | OB59 and current FCV CustomizingT044A / valuation-area and principle assignment objects |
Customizing |
| Core | Chart of accountsForeign-currency valuation | Define unrealized gain/loss and adjustment account determinationDepends on: Valuation method, account types and chartProof: Valuation and reversal journals reconcile to the valued population and configured accounts. | OB09 / OBA1 as applicableT030H / T030HB |
Customizing |
| Core | Company codeAccruals | Configure and operate governed accrual/deferral processingDepends on: Accrual policy, approval, calculation, reversal and evidenceProof: Population, calculation, journal, reversal and reviewer approval are reproducible. | Manage Manual Accruals / Accrual Engine apps; FBS1 only for approved simple casesAccrual objects / ACDOCA |
Methods are configuration; objects and runs are operational data |
| Core | Company codeRecurring journals | Use recurring entries only for stable, approved posting patternsDepends on: Validity, frequency, amount logic, review and end dateProof: Scheduled posting matches the approved template and stops at expiry. | FBD1 / recurring-entry processingRecurring document / resulting ACDOCA |
Operational document data |
| Core | Company code / chartRegrouping | Configure receivable, payable, and GR/IR regrouping where policy requires itDepends on: Maturity, changed-reconciliation-account and balance-sheet presentation policyProof: Close postings and reversals reclassify the correct population and reconcile to source open items. | OBBU / OBBV / OBBW / OBYP and close appsT030U / T030 keys BNG and GNB |
Customizing |
| Confirm | Controlling areaAllocations | Define allocation cycles and tracing factors for approved close allocationsDepends on: Sender/receiver population, driver, version, ledger and reversal designProof: Run log, tracing factors, sender credit, receiver debit and totals reconcile. | Manage Allocations / KSV1 / KSU1 where applicableUniversal Allocation objects or T811* compatibility objects |
Configuration or governed application content; cycles require ownership |
| Legacy | Company codeG/L planning | Exclude deprecated classic G/L planning transactions from the S/4HANA core pathDepends on: Transition assessment and approved replacementProof: Planning need is met through the selected current planning product or explicitly documented as out of scope. | GLPLINST / GLPV / GLP2 / GLPADMFINS_DEPR_OBJECT / classic planning tables |
Deprecated compatibility content |
IMPLEMENTATION REGISTER
Build statements and protect the close
8 of 8 entries shown
| Status | Scope / area | Task, dependency, and proof | Access / objects | |
|---|---|---|---|---|
| Core | Client / chartFinancial statements | Define and govern the financial statement hierarchyDepends on: Chart, reporting policy, retained earnings and ownershipProof: All in-scope accounts are assigned once and statements drill to journal detail. | Manage Global Hierarchies / OB58 where applicableFINSC_FAGL_FSV / hierarchy repository objects |
Tool- and release-dependent hierarchy deployment |
| Core | ChartRetained earnings | Define retained-earnings account determinationDepends on: P&L account types and year-end carry-forward designProof: Balance carryforward closes P&L accounts to the expected retained-earnings account. | OB53T030 key BIL |
Customizing |
| Confirm | HierarchySemantic reporting | Assign semantic tags only for reports that consume themDepends on: Selected analytical report and KPI definitionProof: The target report derives the intended semantic measure from the assigned hierarchy nodes. | FINSC_SEM_TAG / FINSC_FAGL2SEMTAFINSC_SEM_TAG / FINSC_FAGL2SEMTA |
Customizing or governed hierarchy content |
| Core | Company / ledger / periodClose reporting | Run balance sheet and income statement and reconcile to the trial balanceDepends on: Complete hierarchy, approved ledger/currency and posted close adjustmentsProof: Statements reconcile by company, ledger, currency and period and drill to source documents. | F0708 / Display Financial Statements; F.01 where applicableACDOCA / hierarchy objects |
Report parameters and variants are governed separately |
| Confirm | Company pairs / group unitsIntercompany reconciliation | Use ICMR when activated; do not substitute classic ICR assumptionsDepends on: Activated scope, matching rules, data sources, ownership and close processProof: Matched, unmatched, adjusted and approved populations reconcile between counterparties. | ICMR Fiori appsICMR matching and reconciliation objects |
Product-specific configuration and operational cases |
| Legacy | Company codeIntercompany reconciliation | Treat FBIC3 and classic ICR tables as legacy transition referencesDepends on: Source-system assessmentProof: Target reconciliation is designed and proven in the selected S/4HANA capability. | FBIC3FBICRC* |
ECC/classic application content |
| Confirm | Country / company codeTax and statutory reporting | Keep tax procedures, tax codes, statutory forms, e-reporting and local branches in a localization workstreamDepends on: Country scope, legal advice, localization activation and tax ownershipProof: Country acceptance tests reconcile tax base, calculated tax, postings, return and audit evidence. | FTXP / OB40 / localization-specific apps and activitiesT007* / T030K / localization-specific objects |
Localized Customizing plus governed certificates, forms and interfaces |
| Confirm | GroupClose orchestration and consolidation | Implement Advanced Financial Closing or Group Reporting only as approved extensionsDepends on: License, group design, tasks, roles, data mapping and operating modelProof: Task evidence or consolidated values reconcile to the approved entity close without changing the core R2R proof. | Product-specific Fiori appsProduct-specific close and consolidation objects / ACDOCU where applicable |
Separately licensed product and content boundary |
RETURN TO THE WORKBENCHContinue the controlled company-code close
Open R2R 404Use the main workbench for the end-to-end proof from foundation through lock.