Full questions with full answers — no sign-in required.
hardAccounts Receivable
1. In an Order-to-Cash scenario, a customer underpays an invoice due to a pricing dispute and AR posts this using residual payment. Explain how the residual open item's tax treatment integrates with the original SD billing document's tax code, and what happens when SD later issues a credit memo to resolve the dispute, from a tax reconciliation perspective.
The residual item created by the payment posting carries forward the same tax code and tax base proportionally reduced only if configured to recalculate tax on the residual; by default the residual item is simply the unpaid difference and does not automatically re-trigger tax recalculation, since the original invoice's tax was already posted and reported in the period it was created. When SD later issues a credit memo to formally resolve the dispute, that credit memo generates its own tax line reducing the previously reported output tax, which must reconcile with the residual item being cleared in FI. This means the AR team must ensure the residual item is cleared against the SD credit memo rather than left open, otherwise the VAT return may show a mismatch between invoiced and adjusted tax amounts for that period.
mediumGeneral Ledger
2. How do you configure parallel accounting in S/4HANA to handle different valuation requirements, such as IFRS versus local GAAP with different tax depreciation rules, across accounting principles, and what governance is needed over GL account master data to support this?
Parallel accounting in S/4HANA is typically implemented using the ledger approach: you define multiple ledgers—leading ledger for group/IFRS, non-leading ledger(s) for local GAAP or tax—each linked to an accounting principle, and assign them to the relevant company codes. Where valuation genuinely differs, such as different depreciation methods for tax purposes, you configure separate depreciation areas in Asset Accounting posting to the corresponding ledger group, so only the ledger-specific document carries the differential posting. Governance-wise, GL account master data must be carefully controlled so accounts used for principle-specific adjustments, such as a local-GAAP-only provision account, are correctly flagged for the right usage, and changes to key fields like account type or field status require a change-control process since master data is shared across ledgers, not duplicated. Regular reconciliation of ledger balances against source documents helps confirm parallel postings are landing correctly.
mediumGeneral Ledger
3. During year-end close, your reporting team discovers that certain SD billing document revenue postings are hitting a GL account that isn't correctly grouped under 'Revenue' in the Financial Statement Version, causing the income statement to misstate gross revenue. As the FI consultant, how would you investigate the chart of accounts and account determination setup, and correct this before financial statements are finalized?
First, trace the SD document flow to identify which condition type and account key in the pricing procedure determined the GL account via account determination (VKOA), and verify whether the account posted actually matches the intended revenue account in the operational chart of accounts. Then check its assignment in the Financial Statement Version hierarchy. If the account is correctly a revenue account but placed under the wrong FSV node, the fix is at the FSV mapping level, and simply correcting the node reference resolves the reporting distortion without touching posted data. If instead the wrong GL account was actually posted due to a VKOA condition table error, correct the account determination going forward and consider a manual reclassification journal entry for the amounts already misposted. Any correction found this late must be documented, reviewed for materiality, and approved as part of the close checklist, with tightly controlled access to FSV and account determination changes to prevent recurrence.
hardAccounts Receivable
4. Walk through how a customer bill of exchange receivable is posted using a Special GL indicator in AR, and explain how it integrates with bank accounting when the bill is later discounted or collected through the house bank.
The bill of exchange is posted against the customer using a Special GL indicator (e.g., W) that redirects the posting from the standard reconciliation account to a bill-of-exchange receivable GL account while keeping it linked to the original customer open item for reporting. When the bill is discounted with the bank before maturity, a contingent liability posting (often another Special GL transaction) is created to reflect the bank's recourse until the bill's maturity, and the house bank clearing account receives the discounted proceeds net of bank charges/interest. At maturity, when the bill is honored or collected, the special GL item is cleared, the contingent liability is reversed, and the actual bank account is updated through electronic bank statement or manual bank posting, tying the AR subledger back to bank accounting.
mediumAccounts Payable
5. What payment methods are typically configured in the Automatic Payment Program for vendor payments, and what report would you use during AP month-end close to reconcile actual payment method usage against MM-driven vendor invoices?
Common payment methods configured include check, wire/bank transfer, and ACH/direct debit equivalents, each defined in FBZP with country-specific requirements (form, currency, bank details format). During month-end close, I'd use the payment run log/output list from F110 to review which payment method was applied per document, and cross-reference with FBL1N or the vendor line item display to confirm invoices originating from MM (via MIRO) were settled through the payment method specified on the vendor master or overridden at invoice level. Discrepancies often stem from vendor master default payment method changes not syncing with open invoices already posted with a different method.
mediumAccounts Receivable
6. What standard reports or tools would you use to review a customer's dunning history and current dunning level, and how does an SD-driven credit or delivery block interact with the dunning process for that customer?
Dunning history and levels can be reviewed via the customer line item display and the dunning history stored against each open item, which shows the last dunning date, dunning level, and dunning procedure assigned on the customer master company code segment. The dunning program itself is run and monitored through the dunning proposal/run transactions where you can review the proposal log per customer before printing notices. An SD-driven credit or delivery block does not directly stop the dunning run, but a rising dunning level can feed into the customer's credit score or trigger a manual credit block, and conversely resolving overdue items through payment can help clear an existing SD block once the receivable is cleared.
