Select Two (Multi-Select) Questions

Purchasing Organization

Why it fails: The purchasing organization is an organizational unit in the Materials Management (MM) module, responsible for procurement activities. While it is linked to financial processes via invoice verification, it is not a core component of the Finance organizational structure itself, unlike the controlling area or company code.

Shipping Point

Why it fails: The shipping point is an organizational unit in the Sales and Distribution (SD) module. It represents the location where shipping activities are carried out. It is not part of the Financial Accounting organizational structure and does not have a direct impact on the core ledger configuration.

Create a new ledger for document splitting.

Why it fails: Document splitting is not ledger-specific; it applies to the general ledger and is activated per company code. You do not need to create a separate ledger for splitting. The existing ledger (e.g., leading ledger) will store the split line items. Creating a new ledger is unnecessary and would complicate the architecture.

Define a document type for splitting postings.

Why it fails: Document splitting uses the existing document types; you do not need a dedicated document type. Splitting is applied based on the splitting method and rules, regardless of the document type. A separate document type would not influence the splitting logic and is not required for activation.

Assign a segment to each profit center.

Why it fails: While segment derivation often uses profit centers, assigning a segment to each profit center is part of master data setup and may be necessary for segment reporting, but it is not a step to activate document splitting itself. Activation requires the company code setting and a splitting method; segment assignment is a prerequisite for correct derivation but not for activation.

Change the fiscal year variant of the company code to match the calendar year before posting closing entries.

Why it fails: The fiscal year variant is a foundational configuration assigned to the company code and cannot be casually changed mid-year, since it defines posting periods and carryforward logic. Adjusting it during month-end close would disrupt period control and is never a standard closing activity, so this option is clearly outside the normal task list.

Define a new document type for all closing entries and activate it for the current posting period.

Why it fails: Document types are configuration objects created once and reused across periods, not something redefined each month. Closing entries use existing document types such as the standard accrual or closing document types. Creating a new document type during close adds no value and is not part of the recurring month-end task list.

Run the balance carryforward program for all G/L accounts to move current-year balances into the new fiscal year.

Why it fails: Balance carryforward is a year-end activity performed when closing the fiscal year, not a monthly task. Running it at month end would be premature and could interfere with the ongoing fiscal year balances. Monthly close focuses on valuation, accruals, reconciliation, and reporting rather than transferring balances between fiscal years.

Update the chart of accounts to include the missing G/L accounts in the financial statement version.

Why it fails: The chart of accounts defines the accounts but does not control their appearance in the FSV. Updating the chart of accounts does not assign accounts to FSV nodes. The FSV is maintained separately via transaction FSE2 or the Manage Financial Statement Versions app. Therefore, modifying the chart of accounts will not resolve missing accounts in the report.

Activate the 'Financial Statement Version' checkbox in the company code settings.

Why it fails: There is no such checkbox in company code settings. The Financial Statement Version is assigned in the general ledger configuration, but it is not activated via a company code checkbox. The FSV is selected when running the report (e.g., transaction FSE2 or via the Fiori app). Its availability does not depend on a company code setting, so this action is unnecessary.

Run the 'Balance Carryforward' program to transfer balances to the new fiscal year.

Why it fails: Balance carryforward is a year-end closing activity that transfers balance sheet account balances to the new fiscal year. It does not affect the inclusion of accounts in the FSV. Missing accounts in the FSV are due to missing assignments or incorrect account types, not due to carryforward. Running carryforward would not make accounts appear in the financial statement.

It requires periodic batch reconciliation runs between FI-GL and Asset Accounting subledgers.

Why it fails: Asset Accounting is fully integrated into the Universal Journal in SAP S/4HANA. Asset postings write directly to table ACDOCA in real-time, removing the need for periodic reconciliation batch jobs between general ledger and asset accounting subledgers.

It increases database footprint size significantly by duplicating transaction data across multiple application indexes.

Why it fails: The Universal Journal actually reduces the database footprint size. By eliminating redundant total tables and secondary index tables like BSEG and COEP for many scenarios, data storage is optimized while query performance is enhanced.

It restricts parallel accounting to a maximum of two concurrent ledgers per client.

Why it fails: SAP S/4HANA supports an unlimited number of custom non-leading ledgers alongside the leading ledger. There is no architectural restriction limiting parallel accounting structures to two ledgers within a client environment.

It stores data in non-cumulative structures.

Why it fails: ACDOCA is a standard database table, not a non-cumulative structure. While the system can calculate non-cumulative values, the table itself stores individual line items. This design allows for flexible reporting and drill-down capabilities, whereas non-cumulative structures were used in older systems to store aggregate balances for specific reporting needs.

It requires manual reconciliation between FI and CO.

Why it fails: One of the core benefits of the Universal Journal is the elimination of manual reconciliation. Because FI and CO data now reside in the same table, the system ensures that every document creates an entry that is immediately visible across both modules, removing the historical requirement for complex reconciliation procedures.

It is only used for local GAAP reporting.

Why it fails: The Universal Journal supports all accounting principles through the ledger approach. It is not limited to local GAAP but can manage multiple parallel ledgers simultaneously, allowing companies to report according to IFRS, US GAAP, and local requirements within the same database environment with full audit trail integrity.

Create a payment run schedule.

Why it fails: A payment run schedule is used to automate the payment program to run at specific times. It is not required to run the payment program manually. You can execute the payment program directly without a schedule. The schedule is an optional convenience for recurring runs. The essential configuration includes payment methods and house banks, not the schedule.

Configure a check lot.

Why it fails: A check lot is required only if you use checks as a payment method. It defines the range of check numbers. If you only use bank transfers or other electronic methods, a check lot is not necessary. Therefore, it is not a general requirement for the payment program. The payment program can run without check lots if no check payment method is used.

Define a dunning procedure.

Why it fails: A dunning procedure is used for dunning customers who have overdue receivables. It is not required for the payment program, which handles outgoing payments to vendors and incoming payments from customers. Dunning is a separate process for collections. While dunning may be configured in the same company code, it is not a prerequisite for running the payment program.

In the payment method per country configuration, define the payment method as 'Payment Method Supplement' for the vendor.

Why it fails: The payment method supplement is used to differentiate payment methods for the same vendor, but it does not control which payment method is used for the payment run. It is an additional indicator that can be used for grouping, but not for restricting payments to a specific payment method. The requirement is to make payments only to vendors with a specific payment method, which is controlled by the payment method in the vendor master and the payment run parameters.

In the payment program configuration, define a separate payment run for each payment method by creating a new run ID.

Why it fails: Creating separate run IDs does not restrict the payment method; you can still select any payment method in the parameters. The run ID is just an identifier for the payment run. To restrict to a specific payment method, you must specify it in the run parameters and ensure the vendor master has that payment method. Simply creating separate run IDs does not achieve the requirement.

In the payment program configuration, set the 'Payment Method' to 'Mandatory' for the vendor's payment method.

Why it fails: There is no standard configuration setting that makes a payment method mandatory for a vendor. The payment method is simply assigned in the vendor master. The concept of 'mandatory' is not applicable here. Therefore, this option is incorrect and not a valid configuration step in the payment program.

Enable the 'Segment' field in the company code global parameters.

Why it fails: The 'Segment' field is a standard field in SAP S/4HANA and is available by default. Enabling it in global parameters is not a standard configuration step for document splitting. Instead, the segment is derived from the profit center or manually entered. Document splitting configuration focuses on rules and activation, not on enabling the field itself. Thus, this step is not necessary.

Assign the segment to each business partner master record.

Why it fails: The segment is typically derived from the profit center assigned to the business partner or the cost object, not directly from the business partner master record. While business partners may have profit centers, the segment is not a field in the business partner master. Therefore, assigning segment directly to business partners is not a valid configuration step for document splitting.

Configure a new ledger for segment reporting.

Why it fails: While segment reporting may require a ledger that supports segment as a characteristic, creating a new ledger is not a mandatory step for document splitting itself. Document splitting can be used with the existing leading ledger if it includes the segment characteristic. The focus is on activating splitting and defining rules, not on creating a separate ledger. Therefore, this step is not required for the stated purpose.

A dunning level and dunning frequency to manage overdue payments.

Why it fails: Dunning levels and frequencies are configured in the dunning procedure, not in payment terms. They are used to send reminders for overdue invoices. While they are related to payment behavior, they do not influence the calculation of discounts or due dates. The scenario focuses on discount and due date calculation, so dunning settings are not required here.

A tolerance group for the customer to allow payment differences.

Why it fails: Tolerance groups define acceptable payment differences for customers or vendors, such as overpayments or underpayments. They are not part of the payment terms configuration and do not affect the calculation of cash discounts or due dates. While tolerance groups are important for payment processing, they are separate from payment terms and not required to fulfill the scenario.

A payment method indicator, such as 'C' for check or 'T' for bank transfer.

Why it fails: Payment method indicators are used in the Automatic Payment Program to determine how payments are made. They are not part of the payment terms configuration. While payment methods are important for outgoing payments, they do not affect the calculation of cash discounts or due dates for customer invoices. Therefore, this setting is not required to meet the scenario's requirements.

Configure a dunning procedure to automatically deduct the discount after 10 days.

Why it fails: A dunning procedure is used to manage overdue receivables by sending reminders and charging interest. It does not calculate or apply cash discounts. Discounts are handled during payment posting based on the payment terms. Dunning is unrelated to the timing of discount eligibility and would not achieve the desired automatic discount calculation.

Create a new payment method for the discount and assign it to the customer.

Why it fails: Payment methods (such as check or bank transfer) are used to determine how payments are made and are configured separately from payment terms. While payment methods can have their own discount settings, the basic cash discount within payment terms does not require a new payment method. The scenario only asks for a discount based on timing, not a specific payment method, so this step is unnecessary.

Set up a special G/L indicator for the discount to post to a separate discount account.

Why it fails: Special G/L indicators are used for special transactions like down payments or bills of exchange, not for standard cash discounts. Cash discounts are automatically posted to the discount expense or revenue accounts configured in the payment terms Customizing. Creating a special G/L indicator would not be required and would complicate the process unnecessarily.

Define the depreciation area as a derived area from the book depreciation area.

Why it fails: Derived areas are used to calculate depreciation based on another area's values, but they do not inherently post to G/L or serve cost accounting. The question requires the area itself to post and be cost accounting relevant, which is not achieved by derivation alone.

Assign the depreciation area to a ledger group in the ledger configuration.

Why it fails: Ledger groups are used to assign accounting principles to ledgers, but they do not control whether a depreciation area posts to G/L or is used for cost accounting. This setting is about ledger-specific accounting, not the depreciation area's posting or cost accounting behavior.

Set the 'Active' indicator for the depreciation area.

Why it fails: The 'Active' indicator simply enables the depreciation area for use, but it does not ensure G/L posting or cost accounting relevance. An active area could still be non-posting and not cost accounting relevant. Thus, it alone does not fulfill the requirements.

Field status group

Why it fails: The field status group is not defined in the document type; it is defined in the G/L account master record (company code segment) and controls which fields are required, optional, or suppressed during entry. The document type does have a field status group, but it is used for the document header and is not the main control for posting behavior. However, the question asks for settings that must be defined in the document type configuration to control posting behavior, and field status group is not a mandatory setting for the document type itself; it is derived from the account.

Posting period variant

Why it fails: The posting period variant is not defined in the document type. It is assigned to the company code and controls which posting periods are open for posting. While it affects posting behavior, it is not a setting within the document type configuration. Therefore, it is not a correct choice for this question.

Posting keys

Why it fails: Posting keys are not defined in the document type configuration. They are defined separately and are used in line items to control the type of posting (debit/credit) and the account type (customer, vendor, G/L). While they are essential for posting, they are not a setting within the document type. Therefore, this is not a correct choice.

Field status group for posting keys

Why it fails: The field status group is assigned to G/L accounts via the account group and controls which fields are required during posting. It is not part of the fiscal year variant. The fiscal year variant deals with period and year definitions, not field status. This setting is unrelated to fiscal year configuration.

Exchange rate type for currency translation

Why it fails: The exchange rate type is used for currency translation and is defined in currency configuration, not in the fiscal year variant. While it is important for foreign currency postings, it is not a setting within the fiscal year variant. The fiscal year variant focuses on period definitions, not currency conversion.

Posting period variant assignment to company code

Why it fails: The posting period variant is separate from the fiscal year variant. While both are assigned to the company code, the posting period variant controls which periods are open for posting for specific account types. It is not a setting within the fiscal year variant. The fiscal year variant defines the periods, but not their open/close status.

Field status group for the G/L account

Why it fails: The field status group is defined in the G/L account master record, not in the document type. It controls which fields are required, optional, or suppressed during posting for that specific account. The document type does not determine the field status group; it is a separate configuration.

Posting period variant for the company code

Why it fails: The posting period variant is assigned to the company code and controls which periods are open for posting. It is not a setting within the document type. The document type does not influence the posting period variant; that is defined at the company code level.

Reversal reason default

Why it fails: The reversal reason default can be set in the document type configuration, but it is not a mandatory or primary setting controlled by the document type. The document type primarily controls number ranges and allowed account types. Reversal reason is optional and can be defaulted but is not a core control like the others.

Configure a validation rule to enforce segment entry.

Why it fails: A validation rule can enforce that a segment is entered, but it is not required for document splitting. Document splitting itself derives the segment from other dimensions, such as profit center, based on configuration. Validation is an additional control and not a prerequisite for splitting. Therefore, this configuration is not required to implement document splitting for segment reporting.

Define a financial statement version that includes segments.

Why it fails: A financial statement version is used for reporting, such as generating a balance sheet or profit and loss statement. While it can include segments for reporting purposes, it is not a configuration requirement for document splitting itself. Document splitting operates at the posting level and does not depend on the financial statement version. Therefore, this option is not required.

Set up a substitution rule to populate the segment field.

Why it fails: Substitution can be used to populate the segment field automatically, but it is not a required configuration for document splitting. Document splitting uses the splitting method and rules to determine the segment. Substitution is an alternative or supplementary tool, but not a mandatory step. Thus, it is not required for implementing document splitting.

Special Purpose Ledger Groups

Why it fails: Special purpose ledger groups are not part of Asset Accounting organisational setup. The mandatory elements are chart of depreciation, depreciation areas and asset classes, assigned to company code and chart of accounts. Special purpose ledgers belong to General Ledger extension ledgers, relevant when parallel valuation reporting is required.

Consolidated Business Area Hierarchies

Why it fails: Business area hierarchies are optional reporting structures in SAP S/4HANA Asset Accounting, not mandatory organisational elements. The required components are chart of depreciation, depreciation areas and asset classes. Consolidated business area hierarchies would suit multi-company consolidated reporting, not the foundational setup this scenario demands.

Requirement for periodic reconciliation runs.

Why it fails: A major benefit of S/4HANA is the elimination of reconciliation requirements. Because the asset sub-ledger and the G/L share the same data source, data is always consistent. Claiming that reconciliation is still a requirement is factually incorrect and ignores the fundamental architecture of the new accounting system.

Dependency on the old total table FAGLFLEXT.

Why it fails: FAGLFLEXT is an obsolete table from the classical SAP GL. Relying on it would negate the benefits of the S/4HANA migration. The new architecture replaces such total tables with real-time aggregation in the Universal Journal, making the legacy table structure irrelevant and inefficient in an S/4HANA environment.

Customer Credit Limit.

Why it fails: Customer credit limits are part of the Receivables management process, not the bank accounting configuration for payments. While they relate to business partners, they have no functional role in the configuration of bank accounts or the setup of the automated payment program for settling vendor liabilities or bank transfers.

Vendor Material Number.

Why it fails: Vendor material numbers are used in Purchasing and Logistics to identify products, not in Bank Accounting. They are unrelated to the financial process of paying vendors. Including them in the bank configuration would be irrelevant and would not contribute to the setup of payment media or bank master data.

It requires separate total tables for every module.

Why it fails: The Universal Journal eliminates the need for separate total tables (like GLT0 or COSS). All aggregates are calculated on the fly, which drastically reduces the database footprint and increases processing speed. The design intent was to minimize redundancy and complexity by moving from a multi-table approach to one central repository.

It is not possible to add customer-specific fields to the table.

Why it fails: SAP provides the 'Coding Block' feature specifically to append customer-specific fields to the ACDOCA table. These fields are then available for reporting and accounting document entry, ensuring the system remains flexible enough to meet unique business requirements while maintaining the benefits of the central Universal Journal structure.

All line items are converted to the currency of the controlling area.

Why it fails: The Universal Journal supports multiple currencies simultaneously (up to 10). It does not force a conversion to the controlling area currency as the primary storage format; rather, it stores amounts in transaction, company code, group, and other configured currencies, ensuring comprehensive multi-currency reporting without requiring secondary tables or manual conversions.