ERPClimb logoERPClimb

SAP FICO Accounts Payable Interview Questions

In SAP FICO rounds, accounts payable questions are where configuration knowledge meets day-to-day behaviour — what a setting does, and what breaks in a live system when it is wrong.

Accounts Payable (AP) in SAP FI/CO manages the full lifecycle of vendor obligations - from vendor master data and invoice capture through payment and reconciliation with the general ledger. This topic covers the business purpose of AP, vendor master and organizational structures, core configuration for account groups and reconciliation accounts, the document posting and payment flow, integration with MM and GL, controls and reconciliation practices, and how S/4HANA's Universal Journal changes AP data architecture and reporting.

This page carries 47 reviewed SAP FICO accounts payable interview questions, each with a complete written answer and no sign-in required. The set breaks down into 9 foundational, 20 mid-level and 18 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

Rehearse these out loud rather than reading them. If you can explain each answer in your own words, including one realistic way it goes wrong on a project, you are covering what a normal SAP FICO round on accounts payable expects.

47 Accounts Payable questions with answers

easyAccounts Payable

1. What is the role of Business Partner Grouping and its linked number range configuration when creating a Supplier in S/4HANA, and how does this determine whether the vendor account number is assigned internally or externally, and stays synchronized with the classic vendor account group used by MM?

In BP-centric supplier creation, the BP grouping (configured in SPRO under BP number ranges) is mapped 1:1 to a vendor account group via the customer/vendor integration settings. This mapping determines the number range used and whether numbering is internal (system-assigned) or external (user-entered), and it must match the account group's number range settings in the classic vendor configuration (OBAS/vendor account groups) so BP and vendor numbers stay synchronized. If groupings and account groups aren't aligned, BP creation fails or creates mismatched vendor numbers, breaking MM purchasing org data assignment.
easyAccounts Payable

2. What is a Business Partner (BP) with the Supplier role in SAP, and what basic master data elements make up a supplier record?

In S/4HANA, the Business Partner is the single entry point for creating and maintaining supplier master data. A BP is created with role FLVN1 (Supplier), which generates the vendor master (LFA1, LFB1, LFM1) in the background. The BP structure separates general data (name, address, tax numbers), company code data (reconciliation account, payment terms, bank details), and purchasing organization data (order currency, terms of delivery). This unified model replaces the classic direct XK01 vendor creation used in ECC, though ECC still allows classic maintenance.
easyAccounts Payable

3. A vendor sends a credit memo for returned goods that were originally invoiced with a tax code. How would you post this credit memo in SAP, and what should you check to ensure it reconciles correctly against the original invoice?

Post the credit memo using FB65 or MIRO (credit memo type) referencing the same vendor, tax code, and amount proportion as the original invoice line, ensuring the tax code matches so output/input tax is correctly reversed. Check that the credit memo references the original PO/invoice if MM-related, so quantities and tax base align. Verify the vendor line item can be matched and cleared against the original invoice using F-44 or automatic clearing, and confirm the GL tax account and vendor reconciliation account both reflect the reduced liability accurately.
easyAccounts Payable

4. What is the role of the Business Partner Supplier role in the Procure-to-Pay process, and how does purchasing-relevant data maintained on the BP support integration with MM?

In S/4HANA, a supplier is created as a Business Partner with the FLVN00/Supplier BP role, combining general data, company code (FI) data, and purchasing organization (MM) data under one record. Purchasing data such as order currency, incoterms, purchasing block, and partner functions determine how the vendor is used in purchase orders and goods receipts. FI company code data drives reconciliation account, payment terms, and dunning. This unified structure ensures MM documents (PO, GR, invoice via MIRO) and FI postings reference consistent master data, avoiding mismatches between procurement and payables.
easyAccounts Payable

5. In SAP, what is a Business Partner (BP) for a Supplier, and how does it differ from the classic vendor master approach in ECC?

In S/4HANA, the Business Partner is the single point of entry for creating and maintaining supplier master data; the vendor master (LFA1/LFB1/LFM1) is generated and kept in sync automatically via the BP-to-vendor synchronization framework. In ECC, vendors were maintained directly via XK01/FK01/MK01 without a BP layer. S/4HANA mandates BP creation for suppliers (transaction BP), enforcing a role-based structure (FLVN00/FLVN01) that integrates FI and MM views under one business partner ID, improving master data governance, duplicate checking, and reuse across customer/vendor relationships.
easyAccounts Payable

6. What is a Business Partner (BP) with the Supplier role in SAP, and why does S/4HANA require this model instead of the classic vendor master transactions?

In S/4HANA, the Business Partner is the single entry point for creating and maintaining supplier master data. The BP holds general data (address, communication, bank details) while supplier-specific roles like FI Vendor and Purchasing add company code and purchasing organization data. Classic transactions like XK01/FK01 are no longer supported for creation in S/4HANA; BP transaction (BP) is mandatory, using a Customer/Vendor Integration (CVI) synchronization to keep the classic vendor tables (LFA1, LFB1) updated in the background for compatibility with FI/MM processes.
easyAccounts Payable

7. In the Business Partner model for Suppliers, what is the relationship between the BP General Data, the Supplier role, and the Company Code segment, and why can a supplier exist as a BP without being usable in FI postings?

The BP is the central master object holding general data (name, address, bank details, tax info) shared across roles. The Supplier role activates purchasing/vendor-specific views, while the Company Code segment (created via BP transaction with the FI company code role) stores reconciliation account, payment terms, and dunning data required for financial postings. A BP can exist with only general/purchasing data and no company code extension, meaning MM purchasing activity could occur but FI invoice posting is blocked until the company code segment is created, since the reconciliation account assignment lives there.
easyAccounts Payable

8. What is a Business Partner (BP) with the Supplier role, and what basic master data structure supports it in the context of Procure-to-Pay integration with MM?

In S/4HANA, the Supplier is created as a Business Partner using BP transaction with the 'Supplier' role assigned (FLVN1 or similar role category), which synchronizes automatically to the vendor master tables (LFA1, LFB1, LFM1) via the BP-Vendor integration model. General data (name, address, bank details) lives at the BP/client level, while company code data (reconciliation account, payment terms) and purchasing organization data (order currency, INCO terms) are maintained in separate segments. This unified model replaces separate XK01/FK01 vendor creation transactions used in ECC, ensuring one master record drives both FI and MM processes.
easyAccounts Payable

9. When creating a Business Partner with the Supplier role for a new procurement vendor, what purchasing-relevant data must be maintained beyond the FI company-code data so that MM can process purchase orders and goods receipts against that supplier, and where does this data live within the BP structure?

Beyond the BP general data and company-code (FI) view, the supplier needs a Purchasing Organization data view maintained via the BP transaction (role FLVN00/Supplier Purch.), which stores order currency, terms of payment at the purchasing org level, Incoterms, GR-based invoice verification indicator, minimum order value, and partner functions (ordering address, goods supplier, invoicing party). Without this purchasing view assigned to at least one purchasing organization, MM cannot reference the vendor on a purchase order. The BP model synchronizes this data to classic tables LFA1/LFB1/LFM1 in the background.
mediumAccounts Payable

10. 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 Payable

11. During month-end, several vendor invoices with cash discount payment terms were paid late by the AP team, but the payment run still calculated the discount. How would you investigate and correct this?

First check the payment term configuration (OBB8) for the baseline date and discount days to confirm the discount deadline. Review F110 payment proposal logs to see the payment date used and whether the discount was manually forced or the baseline date was incorrectly derived (e.g., from posting date instead of document/invoice date). Check if a tolerance for discount days was configured allowing grace periods. If the discount was wrongly taken, reverse the payment, correct the baseline date or payment term assignment, and reprocess through F110, ensuring the discount base amount and percentage rates are accurate for future runs.
mediumAccounts Payable

12. During AP month-end close, several vendor invoices with cash discount payment terms were paid late by the treasury team, yet the payment run still calculated and applied the cash discount. How would you investigate and correct this?

First check the payment terms configuration (OBB8) to confirm the discount days and percentages, then review the baseline date on each invoice (posting date, document date, or invoice receipt date) since an incorrect baseline pushes out the discount deadline. Check F110 parameters, especially the payment run date and next payment run date, as a payment can still qualify if run before the true due date despite actual execution occurring later. Correct affected postings by adjusting baseline dates if wrong, or reversing/reissuing payments if discount was genuinely invalid, and communicate cutoff rules to AP to prevent recurrence.
mediumAccounts Payable

13. What payment methods are typically configured for vendor payments through the Automatic Payment Program, and what reports would you use during AP month-end close to reconcile actual payment method usage against MM-driven vendor invoices?

Common payment methods configured in FBZP include check, wire transfer, and ACH/direct debit, each defined per country with specific form/output requirements and bank/GL account assignments. During month-end close, you would use the payment run log (F110 output) and the vendor line item report (FBL1N) filtered by payment method to confirm all invoices, particularly those originating from MM goods receipt/invoice receipt, were settled using the vendor master's assigned payment method. Cross-checking the payment medium file/output against bank statements ensures the correct method was executed and no invoices were missed or paid via an unintended method.
mediumAccounts Payable

14. During AP month-end close, several vendor invoices with cash discount payment terms were paid after the discount deadline via the outgoing payment run, yet the discount was still applied. How would you investigate and correct this?

First check the payment terms configuration (OBB8) for the discount days/percentage and confirm the baseline date used on the invoice. Review the F110 payment proposal log and parameters to see if the 'next payment date' or discount tolerance was overridden, since some configurations allow a grace period or manual override of cash discount eligibility. Also check if a payment term with a fixed discount percentage regardless of date was mistakenly assigned. Correct by reversing/re-clearing the payment if the discount was invalid, adjusting the terms of payment master, and tightening F110 parameters to prevent recurrence.
mediumAccounts Payable

15. What payment methods are typically configured in the Automatic Payment Program for vendor payments, and which report would you use during month-end close to confirm the correct payment method was applied per vendor country and payment amount?

Common payment methods include check, wire transfer, ACH/direct debit equivalents, and country-specific methods (e.g., SEPA credit transfer in Europe). Each is configured at the country level (form, currency, minimum/maximum amount) and company code level (bank determination, house bank ranking) in FBZP. During close, the payment run log (F110) and the payment list report can be reviewed, along with the vendor line-item report (FBL1N) filtered by payment method, to confirm invoices were paid using the vendor master's assigned method and that amount limits weren't violated, flagging any manual overrides during invoice entry.
mediumAccounts Payable

16. How is bank determination configured in FBZP for vendor master governance, and how does this configuration integrate with the GL clearing accounts used during AP month-end close?

Bank determination in FBZP requires four linked settings: ranking order of house banks per payment method, house bank accounts, available amounts, and value date/expenses/charges. During F110, the system selects a house bank based on ranking and available balance, then posts the payment to the bank sub-account (GL clearing account) linked to that house bank ID/account ID combination in the House Bank Accounts configuration. At month-end, this GL clearing account must reconcile against the bank statement; mismatches often trace back to incorrect house bank/account ID mapping on the vendor's payment run or a GL account assigned to the wrong house bank.
mediumAccounts Payable

17. Walk through the step-by-step configuration of bank determination in FBZP for automatic vendor payments, including ranking order, bank accounts, available amounts, and value date, and explain how these settings interact to select the correct house bank and GL clearing account.

In FBZP, bank determination has four linked steps: (1) Ranking Order assigns priority per payment method and currency to house banks; (2) Bank Accounts links each house bank/payment method combination to a specific GL account (the bank clearing account) and account ID; (3) Available Amounts sets the amount limit per house bank/account before the next-ranked bank is used, checked daily and reduced as payments are proposed; (4) Value Date defines the number of days between posting and value date per payment method/house bank, used for cash management. F110 evaluates these in sequence during the payment proposal to pick the house bank and post to the correct GL account.
mediumAccounts Payable

18. From a governance perspective, how is bank determination for automatic vendor payments configured to protect the integrity of GL bank clearing accounts, and what sensitive-field controls should be in place when supplier bank details change?

Bank determination in FBZP (or configuration behind the Payment Program) links house bank, ranking order, available amounts, and bank sub-accounts per payment method and currency to specific GL clearing accounts. Because a wrong mapping posts payments to the wrong GL account, governance requires: restricting who can maintain bank determination tables, dual-control/workflow approval on supplier bank account changes (BP sensitive fields trigger a confirmation step before the account is usable for payment), and periodic reconciliation of bank sub-ledger balances to GL. Segregation of duties between master data maintenance and payment run execution is essential to prevent fraud such as redirected payments.
mediumAccounts Payable

19. What payment methods are typically configured in the Automatic Payment Program for vendor payments, and what standard report or table would you use during AP month-end close to reconcile the total amount actually paid per payment method against the payment proposal?

Typical payment methods configured in FBZP/F110 include check, wire transfer, ACH/direct debit equivalents, and country-specific methods (e.g., SEPA credit transfer), each with its own form, currency, and country restrictions. To reconcile actual payments per method during month-end close, you would review the payment run log in F110 (payment summary), the REGUH/REGUP tables which store the payment run header and item details including payment method, or FBL1N filtered by payment method to tie posted clearing documents back to the proposal. Any variance between proposed and paid amounts by method typically points to exceptions during payment medium generation or manually blocked items.
mediumAccounts Payable

20. What payment methods are typically configured for vendor payments in SAP, and what reports would you use to reconcile payment method usage at month-end close?

Common payment methods include check, wire/bank transfer, and country-specific electronic formats (e.g., ACH, SEPA), each configured in FBZP with country-specific settings, form/output configuration, and currency restrictions. At month-end, reconcile payments by reviewing the payment run log in F110 (proposal and payment list), cross-check against the vendor line item report (FBL1N) for cleared items, and review the bank sub-account postings against the bank statement to confirm all payment method outputs were correctly processed and reflected in GL. Any exceptions in the payment proposal log should be resolved before final payment run execution.
mediumAccounts Payable

21. How is bank determination configured to control which house bank and GL account are used during vendor payment runs, and what master data or business partner elements feed into this determination?

Bank determination is configured per paying company code in FBZP, defining ranking order of house banks per payment method, available amounts per bank, and the bank sub-account (GL clearing account) per house bank/account ID combination. During payment proposal, F110 selects the vendor's payment method and currency, checks house bank ranking, available amount limits, and posts to the bank sub-account tied to that house bank/account ID. The vendor BP's bank details (IBAN, bank country) and the payment method assigned on the vendor or invoice line also influence which house bank qualifies, especially for currency or country-specific payment methods.
mediumAccounts Payable

22. During AP close, Treasury flags that vendor invoices set up with an installment payment term (e.g., 40% due in 30 days, 30% in 60 days, 30% in 90 days) are all showing the same single due date in the cash flow forecast instead of three staggered due dates. How would you troubleshoot the payment terms configuration causing this?

Check the terms of payment configuration (OBB8) to confirm 'Installment payment' is flagged and that an installment plan (percentage/terms combination) is correctly maintained; without this flag, the system treats the term as a single due date. Also verify that the invoice was posted using a document type/item category that respects installment splitting, since manual FB60 postings sometimes bypass automatic line splitting if the payment term isn't properly assigned at header level. Once corrected, the system should automatically split the invoice into multiple line items with different baseline/due dates, which will then feed correctly into Treasury's cash flow forecast via F110 due date logic.
mediumAccounts Payable

23. How is bank determination configured for automatic vendor payments in the Automatic Payment Program, and what master data drives the selection of the correct house bank and GL account?

Bank determination for F110 is configured per paying company code in the payment program setup, defining ranking order of house banks, available amounts per bank, and the GL bank sub-account per payment method and currency. The actual bank selected also depends on the vendor's payment method and any house bank explicitly specified on the vendor master or payment document. If no bank is forced at vendor level, F110 selects the highest-ranked house bank with sufficient available funds. Incorrect setup here can cause payments to route through the wrong bank sub-account, breaking GL reconciliation.
mediumAccounts Payable

24. How is bank determination configured for automatic vendor payments, and what master data elements does it depend on?

Bank determination in FBZP defines, per paying company code, ranking order of house banks, available payment methods per house bank, and bank sub-account (GL account) per house bank and currency. It relies on the vendor's payment method, bank details on the vendor master or BP bank data, and the house bank/account IDs configured in FI. During the payment run (F110), the system selects a house bank based on ranking, available amount limits, and the vendor's bank country/currency match, then posts the outgoing payment to the corresponding GL bank sub-account.
mediumAccounts Payable

25. During AP month-end close, finance discovers that several vendor invoices for a specific country were paid via wire transfer instead of the domestic ACH-equivalent payment method mandated by local regulation, even though the vendor master had a default payment method assigned. What configuration and reports would you use to determine why the wrong payment method was selected?

Check FBZP payment method per country configuration to confirm the ACH-equivalent method is even enabled for that country/company code combination, then check the vendor master's allowed payment methods field — if the correct method isn't listed there, F110 falls back to the next available method in the proposal's selection sequence. Review the F110 payment run log/proposal list to see which method was actually selected per item and why. For reporting, use FBL1N filtered by payment method, or review REGUH/REGUP payment run tables to reconcile actual payment methods used against the vendor master default, confirming whether the mismatch stems from master data, country-level FBZP setup, or a manual override during the payment run.
mediumAccounts Payable

26. How is bank determination configured to support automatic vendor payments during month-end AP close, and what role does the GL account assignment play in this configuration?

Bank determination is configured in the Automatic Payment Program (FBZP) by defining ranking order of house banks per payment method and currency, available amounts per house bank/account, and the GL accounts (bank sub-accounts) used for posting outgoing payments. The vendor's payment method and bank details on the master record, combined with FBZP settings, determine which house bank and GL account are used. During month-end close, this configuration ensures payments post to the correct bank clearing GL account, allowing accurate reconciliation between the bank subledger and GL during the closing cycle.
mediumAccounts Payable

27. How is bank determination configured for automatic vendor payments, and what governance controls should be applied to vendor master bank data to protect GL reconciliation during month-end close?

Bank determination in the Automatic Payment Program is configured via ranking order, bank accounts, available amounts, and value date per house bank/payment method combination, linked to the paying company code. The vendor master's assigned payment method and bank details feed into the selection logic during F110. To protect GL reconciliation, sensitive vendor bank data fields should require dual control (change with approval workflow), and changes should be logged and reviewed before the next payment run. Segregating bank master maintenance from AP invoice processing duties reduces fraud risk and ensures the bank clearing account in GL always ties to actual disbursements.
mediumAccounts Payable

28. Treasury reports that a group of vendor invoices with identical payment terms were selected in different payment runs during the same close period, causing inconsistent cash outflow timing. What payment terms and F110 configuration would you check?

First check the baseline date category on the payment terms (document date, posting date, or invoice receipt date) since invoices entered with different reference dates can yield different due dates even under identical terms. Then verify the F110 parameters' 'next payment date' and posting date range used across the runs, as invoices near the run boundary can fall into different proposals depending on run scheduling. Also check for vendor-specific payment term overrides at the line-item level (entered manually during invoice posting) that deviate from the vendor master default, and confirm the company code's tolerance for cash discount grace days wasn't inconsistently applied.
mediumAccounts Payable

29. During an outgoing payment run, Treasury notices that several vendor invoices with a 2/10 net 30 payment term were paid on day 25, well past the discount window, yet the cash discount was still deducted. Investigation shows the baseline date on these invoices was incorrectly defaulting to the posting date instead of the document date. How would you troubleshoot and correct this?

First check the payment terms configuration (baseline date category) to confirm whether it's set to document date, posting date, or a fixed day. If configured correctly for document date but invoices still show posting date as baseline, check whether the invoices were posted via a process (e.g., background job or interface) that doesn't populate the document date field, causing baseline date default logic to fall back to posting date. Review the affected invoices' BSEG baseline date field directly, correct via FB02 where still open, and validate the interface/posting program to ensure document date is always passed. Re-run F110 proposal to confirm discount eligibility recalculates correctly.
hardAccounts Payable

30. In a landscape where vendor advance/down payments are initiated in SAP Ariba and posted in S/4HANA using a Special GL indicator before being netted against final invoices through the Automatic Payment Program, a recent payment run resulted in duplicate payments because down payments failed to net against final invoices. As the integration architect, how would you diagnose the root cause?

Start by verifying the Special GL indicator configuration (transaction OBXR/OBYR) to confirm the down payment GL account and clearing logic are correctly linked to the vendor reconciliation account. Check whether the down payment request/invoice from Ariba was posted with the correct Special GL indicator and vendor reference so F110 can identify it for automatic clearing against the final invoice. Review F110 proposal logs for netting exceptions, and confirm the Ariba-to-S/4HANA interface is passing the original PO/down payment reference consistently, since a mismatched reference or missing Special GL flag will prevent automatic offset, causing full invoice payment alongside the earlier down payment.
hardAccounts Payable

31. In a landscape where vendor down payments are initiated in SAP Ariba and posted in S/4HANA with a Special GL indicator before being netted against final invoices via the Automatic Payment Program, a recent payment run resulted in duplicate payments because down payments failed to net against final invoices. As the integration architect, how would you diagnose the root cause?

Start by checking whether the down payment postings carry the correct Special GL indicator and reference (purchase order/invoice reference) needed for automatic clearing during F110 or via down payment clearing (F-54/F-44). Verify the Ariba interface correctly maps the PO/invoice reference onto the down payment document so the system can match it against the final invoice. Check vendor line item display for both the down payment and invoice to confirm they share matching assignment/reference fields. Also review whether the payment proposal parameters exclude Special GL transactions from netting, which would cause both items to be paid in full.
hardAccounts Payable

32. Walk through how withholding tax on a cross-border vendor invoice is calculated at invoice posting versus at payment posting under Extended Withholding Tax, and explain how this interacts with the outgoing payment's bank accounting output (e.g., payment media/DME) that must carry WHT certificate information.

Under Extended WHT, tax types can be configured 'at invoice posting' and/or 'at payment posting.' Invoice-time WHT withholds tax immediately on booking the payable, while payment-time WHT calculates and posts the withholding only when the payment clears, which is common for statutory requirements tied to actual cash outflow. Both can coexist to handle different tax authorities' rules. On payment, the reduced net amount is transferred to the house bank via F110, and the payment medium/DME format must include WHT certificate data (rate, base amount, tax authority) for statutory reporting. Misconfiguring the WHT type as invoice-only when the country mandates payment-time withholding causes incorrect certificate data and compliance exposure.
hardAccounts Payable

33. Your organization is centralizing house banks into a shared service model where a single house bank serves multiple company codes for vendor payments, and supplier master records reference legacy bank keys. Post-migration, several vendor invoice payments post to the wrong GL clearing account. As the senior architect, how would you diagnose and correct this?

First verify each company code's house bank/account ID combination is correctly mapped to the new shared house bank in FI12/FI12HBank, and that the GL sub-account assigned per house bank/account ID matches the intended clearing account for that company code, since shared house banks can still require distinct GL accounts per company code. Then check supplier BP bank details for outdated bank keys or IBANs referencing the legacy setup, which could cause bank determination in FBZP to select an unintended house bank. Finally, review F110 logs for the affected payments to trace which house bank/account ID was selected, and implement a governance process requiring dual control and testing before house bank consolidation changes go live.
hardAccounts Payable

34. Your organization is consolidating multiple house banks used for vendor payments across regional entities into a shared service center model. What master data and configuration changes are required, and what risks must be managed during the transition?

You must reconfigure house bank IDs and bank account assignments in FI to reflect the new shared house bank structure, updating bank determination in FBZP to map each affected company code's payment methods to the consolidated house bank and correct bank sub-GL accounts. Vendor master bank details and payment method assignments generally remain unchanged, but company code-to-house bank mapping must be revalidated. Risks include duplicate or orphaned open payment items referencing old house banks, incorrect bank sub-account postings during transition, and open items in transit needing careful cutover sequencing to avoid duplicate payments or reconciliation breaks between GL and bank statements.
hardAccounts Payable

35. Walk through how withholding tax is calculated and posted during vendor invoice entry under Extended Withholding Tax, and how this base amount and liability interact with the outgoing payment's bank accounting output.

Under Extended WHT, tax types/codes are assigned to the vendor master, and at invoice posting (FB60/MIRO) the system calculates WHT on the base amount (often net of cash discount) and posts a separate WHT payable line alongside the vendor liability, depending on whether the tax type is defined for invoice-time or payment-time posting. For payment-time WHT types, the tax is only calculated and posted during F110/F-53, reducing the vendor's net payment. The payment run also triggers DME/payment media generation, which must carry WHT certificate data for statutory reporting; misconfigured WHT type timing or incorrect base amount modifiers cause under/over-withholding at payment.
hardAccounts Payable

36. Walk through how withholding tax base amount is determined when a vendor invoice includes both a cash discount term and a partial down payment already cleared, and how the final WHT liability posting reconciles at outgoing payment.

Under Extended Withholding Tax, the WHT base is typically the gross invoice amount net of any excluded items per the WHT type configuration (e.g., exclude VAT), and the base can be reduced further if the WHT type is configured for cash discount adjustment. When a prior down payment cleared with its own WHT deduction exists, the system nets the remaining invoice base so WHT isn't double-deducted, provided the down payment WHT type/code combination matches the invoice's accumulation settings. At outgoing payment, if 'WHT at payment' type is active, the remaining WHT is calculated on the net open balance, and the WHT certificate/reporting reflects both postings tied to the vendor's WHT number.
hardAccounts Payable

37. Walk through how withholding tax is calculated at invoice posting versus payment posting under Extended Withholding Tax, and explain how this interacts with bank accounting output during the outgoing payment run.

Under Extended Withholding Tax, WHT types can be configured for invoice posting time, payment posting time, or both, each with its own tax type/tax code and base amount calculation. At invoice entry, the invoice-time WHT type withholds tax immediately and posts it to a WHT payable account. At payment, the payment-time WHT type calculates tax on the actual cleared amount, which is relevant when discounts or partial payments change the taxable base. During the F110 run, the net payment amount (after WHT deduction) is passed to bank accounting, and payment media/DME formats must carry WHT certificate data required for vendor remittance advice and statutory reporting.
hardAccounts Payable

38. Walk through the end-to-end process of withholding tax calculation on a vendor invoice, and how the outgoing payment posting relates to it under Extended Withholding Tax.

During invoice entry (FB60/MIRO), withholding tax codes assigned to the vendor master are evaluated at the base amount, and depending on configuration, WHT is either calculated at invoice time or deferred to payment time. Extended Withholding Tax supports both 'at invoice posting' and 'at payment posting' types simultaneously, using separate WHT types. At payment (F110/F-53), if payment-time WHT is configured, the system calculates and posts the tax liability, reduces the vendor payment, and posts to the WHT payable account. Certificate numbering and reporting rely on the WHT type/code combination and country-specific settings.
hardAccounts Payable

39. In an SAP Ariba-integrated landscape, vendor down payments are posted in S/4HANA with a Special GL indicator, but the F110 payment proposal consistently excludes these down payments from the run even though they are open and due. As the integration architect, how would you diagnose whether this is a payment proposal parameter issue or a Special GL/reconciliation account configuration issue?

First check the F110 parameter screen (Additional Log/Free selection and the 'Payments' tab) to confirm whether the special G/L indicator is included in the run's selection criteria; by default, F110 does not select special GL transactions unless the indicator is explicitly added. If parameters are correct, check the Special GL configuration (OBXR/OBXY-type transaction assignment) to confirm the alternative reconciliation account is properly linked to the standard vendor reconciliation account and flagged for automatic payment eligibility. Also verify the down payment isn't blocked by a payment block indicator carried over from the Ariba interface. Correct the F110 parameters or configuration accordingly and re-test the proposal.
hardAccounts Payable

40. Walk through the end-to-end process of withholding tax calculation and posting during vendor invoice entry, and explain how this integrates with the subsequent outgoing payment posting under Extended Withholding Tax and bank accounting.

During invoice entry (FB60/MIRO), the system calculates withholding tax based on the WHT type and code assigned to the vendor master and company code configuration, posting a WHT liability line if tax is due at invoice time (invoice-based WHT), or deferring calculation to payment time (payment-based WHT). At payment posting via F110 or F-53, the system either posts the deferred WHT liability or simply clears the invoice, since invoice-based WHT already recorded it. The net payment amount reduces the bank clearing account, with WHT certificates generated for statutory reporting. Misalignment between invoice-based and payment-based WHT types causes double or missing tax postings.
hardAccounts Payable

41. In a landscape where vendor invoices originate from SAP Ariba and flow into S/4HANA for payment via F110, what integration points and special GL considerations must be validated to ensure smooth invoice-to-pay processing?

Validate that Ariba invoice replication correctly maps vendor IDs, PO references, and tax codes to the corresponding S/4HANA business partner and purchase order, typically via middleware (e.g., Ariba Network Integration or Cloud Integration Gateway). Ensure invoices post correctly to FI/MM with accurate GR/IR clearing, and that any advance payments or down payments made against Ariba-sourced POs use the correct special GL indicator (e.g., 'A' for down payments) so they don't distort regular vendor liability reporting. Confirm F110 payment proposal excludes blocked or disputed Ariba invoices, and reconcile special GL down payment balances separately during month-end close.
hardAccounts Payable

42. Walk through how withholding tax is calculated and posted during vendor invoice entry, and how it interacts with subsequent outgoing payment postings.

With Extended Withholding Tax active, WHT types and codes are assigned to the vendor master and configured with base amounts, rates, and posting indicators (invoice-based or payment-based). At invoice posting (FB60/MIRO), invoice-based WHT is calculated and posted immediately as a separate tax line reducing the vendor liability and crediting a WHT payable GL account. Payment-based WHT instead defers calculation until the payment run (F110) or manual payment posting, calculating WHT on the cleared amount at that time. Certificates are later generated via WHT reporting for statutory remittance, and the WHT liability account must reconcile with tax authority filings.
hardAccounts Payable

43. Your company code has multiple house banks, each holding accounts in different currencies, to support vendor invoices posted in USD, EUR, and local currency. After a recent payment run, several USD vendor invoices were paid out of the EUR house bank account, causing FX losses and a GL clearing account mismatch. As the senior architect, how would you diagnose and correct this?

Start by reviewing the bank determination configuration (ranking order and available amounts per house bank/account ID per currency) in FBZP — if the USD-specific house bank account wasn't ranked correctly or wasn't flagged as available for that currency, F110 falls back to the next ranked account, which may be the EUR account, generating an unwanted cross-currency payment and FX exposure. Also check the vendor's payment currency and whether the invoice currency matches an account explicitly configured in the bank determination table; if not, correct the ranking/available amounts, add the missing USD account entry, and rerun the reconciliation between the bank sub-ledger and the GL clearing accounts to true up the FX variance already posted.
hardAccounts Payable

44. Your organization is onboarding a large volume of new suppliers, and supplier master records specify bank details tied to specific house banks used for outgoing payments. Shortly after go-live, GL reconciliation reveals several vendor invoice payments hitting the wrong house bank clearing account, causing bank subledger imbalances against the GL. As the senior architect, how would you diagnose and resolve this?

Start by checking the supplier BP bank details and their linked house bank/partner bank type, then confirm the ranking order and available amounts configured in FBZP for the affected payment methods and currencies. Review whether the vendor master's bank details were correctly maintained during mass onboarding (e.g., via LSMW/migration cockpit), since a wrong or missing partner bank type causes F110 to default to an unintended house bank. Correct the master data, rerun a reconciliation between REGUH/REGUP and the GL bank clearing accounts, and establish a governance checklist requiring dual validation of bank details before activating new suppliers for payment.
hardAccounts Payable

45. In an SAP Ariba-integrated landscape, vendor down payments posted with a Special GL indicator in S/4HANA are expected to net against final invoices during the F110 payment run, but a recent run paid both the down payment and final invoice in full, resulting in duplicate payments. As the integration architect, how would you diagnose the root cause?

I would first verify that the down payment request/document from Ariba was posted correctly with the appropriate Special GL indicator (e.g., 'F' for down payment request or 'A' for down payment) and that the reconciliation account for the Special GL indicator is configured to allow automatic clearing. Next, I'd check whether the final invoice was posted with a reference to the down payment so the system can trigger automatic offset during F110, since without this link the payment program treats both as independent open items. I'd also review F110 parameters to ensure special GL indicators are included in the payment proposal selection, and validate the Ariba-to-S/4HANA interface mapping for down payment clearing indicators.
hardAccounts Payable

46. In an SAP Ariba-integrated landscape, vendor invoices with associated PO-based down payment requests are posted in S/4HANA using a Special GL indicator before F110 nets them against final invoices. A recent payment run paid several down payments and final invoices separately instead of netting. What would you check across the integration and Special GL setup?

First confirm the down payment was posted with the correct Special GL indicator (e.g., 'F' for down payment request or 'A' for actual down payment) and that the special GL account is flagged for clearing against the final invoice via the target special GL configuration in OBXR. Then verify the final invoice from Ariba was posted referencing the same vendor and, if applicable, the same PO so F110 can identify related open items. Also check that the special GL indicator is included in the F110 selection parameters (special GL indicators to be paid) and that the down payment clearing transaction (F-54) ran before or during the same payment proposal, since unlinked down payments remain open and get paid independently.
hardAccounts Payable

47. In an S/4HANA landscape integrated with SAP Ariba, vendor down payments posted with a Special GL indicator are supposed to be netted against final invoices automatically during the F110 payment run, but the payment proposal keeps listing both the down payment and the final invoice as separate open items to be paid in full. What configuration would you check first?

First check the vendor master/FBZP setting that controls whether special GL transactions are included in the payment proposal — specifically whether the special GL indicator used for down payments is flagged to be considered and offset during automatic payment selection. Then verify that the down payment and final invoice share the same assignment/reference so F110 can match them, and check that the down payment clearing (normally done via F-54 or automatically through invoice-based netting) hasn't been skipped, leaving both items open simultaneously. If Ariba posts the down payment and invoice through separate interface batches without a common reference key, F110 has no way to link them for netting.

Related lesson

Automatic Payment Program Configuration and Payment Run Operations

Related topics

General LedgerAccounts Receivable

Next practice step

Practice with Interview AITake a mock test