SAP S/4HANA FI common mistakes
SAP S/4HANA FI · Understand the traps and how to avoid them.
Creates the new document type in OBA7, saves it, then immediately tries a test posting and gets "Number range ... does not exist for ... in year ...", and starts troubleshooting the vendor master instead.
The candidate treats the document type as a standalone object and forgets that a number range interval must be explicitly assigned to the document type in the same transaction (folder "Number ranges" per company code). They also often set the number range as external when the entry screen expects internal, so the field is greyed out or demands a manual number.
What to do instead
In OBA7, after saving the document type, open the "Number ranges" folder for the relevant company code, create or select an interval, and assign it to the document type. Confirm Internal/External matches how users will post, and verify the account type checkboxes (vendor, customer, G/L) are ticked for the account types the type is meant to serve.
Posts a vendor invoice in FB60 with a payment term in the header and then cannot understand why the vendor item never appears in the F110 payment proposal.
The candidate assumes the document header payment terms alone drive payment. In practice the vendor master company-code segment carries the payment method, and the line item carries its own payment block, payment method, and baseline date. A missing payment method in the vendor master, or an item-level payment block, silently excludes the item.
What to do instead
Check the vendor master company code segment (payment methods, payment terms) and the line item fields in FB02/FBL1N: payment method, payment block, baseline date, and the "payment advice"/individual payment indicators. Correct the master data with FK02 or the item with FB02, then regenerate the proposal.
Runs the receivables valuation program with a key date but leaves the valuation method or adjustment key empty, then concludes the program "did nothing" because no adjustment documents were created.
The candidate expects the program to apply a default percentage. Value adjustment is entirely driven by Customizing: the valuation method, the adjustment keys (flat-rate individual, percentage, etc.), the valuation areas, and the assignment of the method to the company code. Without that chain nothing is calculated.
What to do instead
Configure the adjustment keys and valuation method (including whether the adjustment posts to a separate adjustment account or directly to the receivable), assign the method to the company code and valuation area, then run the valuation for the correct key date and fiscal year and review the log before releasing the postings.
Creates a customer invoice in FB70 for a customer whose master is maintained only in the sales area/credit side, and hits "Account ... not managed in company code ..." or a posting that goes to the wrong reconciliation account.
The candidate confuses the credit control area and sales data with the FI company code segment. The reconciliation account is derived from the customer master's company code segment, not from the customer's general data or from the document type.
What to do instead
Maintain the customer in the company code segment (FD02/XD02) with the correct reconciliation account and sort key, and confirm the reconciliation account is marked as a reconciliation account for account type D in the chart of accounts. Test with a small FB70 posting before building the exercise around it.
Defines a house bank and account ID in FI12, then the payment run fails to find a bank or posts to the wrong bank G/L, and the candidate starts editing the vendor bank details.
The candidate stops after entering the house bank ID and account ID and does not assign the bank G/L account (bank sub-account) to the house bank account ID, and does not verify that the bank key/country in the bank directory exists and matches the account number format.
What to do instead
In FI12, verify the house bank (bank country, bank key, SWIFT) and then maintain the account ID with the correct bank G/L account, currency, and any cash concentration/check lot settings. Cross-check the bank directory entry for the bank key and test with a manual payment (F-58) before running the payment program.
Goes straight to the payment run (F110) after creating the proposal parameters, without inspecting the proposal, then reports that "the run paid the wrong vendors" or that exceptions were ignored.
The candidate treats proposal and payment as one step. The payment program is two-phase: the proposal schedule creates the payment proposal with an exceptions log, and only the payment schedule creates payment documents. Skipping the review also hides missing payment methods per country, blocked items, and house bank problems.
What to do instead
Run only the proposal first, open the proposal log and the exceptions list, correct master data or items and regenerate if needed, then run the payment schedule in a separate step. Confirm the payment method per country/company code in FBZP and check the "next payment date" and "payments per run date" parameters.
Posts an external acquisition with transaction type 100 and a capitalization date in a period where depreciation has already been posted, hits an error or gets an unexpected depreciation start, and adjusts the asset master fields at random.
The candidate ignores that the transaction type determines the posting logic and the depreciation start, and that a capitalization date falling in a period already closed for depreciation forces a recalculation that SAP blocks or shifts. They also forget that the depreciation run for the period must be complete before retroactive postings.
What to do instead
Select the transaction type that matches the business event (external acquisition, acquisition with automatic offsetting entry, transfer, etc.), confirm the depreciation key and useful life in the asset master, and ensure the depreciation run for the affected period has not been posted - or explicitly handle the catch-up via the documented post-capitalization route.
Creates a new asset class for a special asset type and then the acquisition posts to the wrong balance sheet account, and the candidate starts changing the asset master account assignment fields.
The candidate does not realise that the G/L accounts for APC, depreciation expense, and accumulated depreciation are determined by account determination (per chart of accounts, depreciation area, and account determination key), not by the asset master or the asset class name.
What to do instead
Maintain account determination for the asset class's account determination key in the depreciation areas involved, verify the account assignment and the depreciation areas that post to FI, then post a test acquisition and inspect the resulting FI document before proceeding with the scenario.
Copies an existing company code and then finds that postings, the payment program, or asset postings fail across several areas - and keeps fixing each symptom individually.
The candidate assumes the copy function produces a complete, self-contained company code. Number ranges, posting keys were fine, but company-code-specific number ranges for the accounting documents, the chart of accounts entries in FS00, the assignment to a credit control area, and the paying company code settings in FBZP usually require explicit follow-up.
What to do instead
After the copy, maintain document number ranges per company code for the relevant document types, verify fiscal year variant and posting period variant, create/open the G/L accounts in the new company code (FS00), assign the company code to a credit control area, and maintain the paying company code and house banks in FBZP. Run a consistency check with a posted test document for each area.
Expects a G/L account's field status group to hide the cost center field, finds it still required, and changes the field status group repeatedly.
The candidate believes one setting controls field status. In fact the screen field status for a journal entry line is the most restrictive combination of the posting key's field status and the G/L account's field status group; a "required" in either place wins.
What to do instead
Check the posting key field status (OB41) and the field status group (OBC4) together, identify which one is setting the field to required, and relax the right one. Then test with a posting in FB50/FB60 to confirm the resulting field state.