Top-Rated SAP S/4HANA FICO Online Course: Why Does the Vendor Invoice Post but the GL Stay Empty?

Introduction :

If you are the SAP FICO Online Training  consultant on support, this is your moment. This exact incident, in many variations, is one of the most common tickets in any S/4HANA finance support queue. It is also one of the best examples of why a top-rated SAP S/4HANA FICO online course should teach you to solve incidents, not just memorize configuration screens.

Ticket title: Vendor invoices posted successfully but not visible in G/L account.

Reported by: Accounts payable lead, forwarded by the financial controller.

Priority: High, because period-end close is running.

Symptoms:

• Invoices show a document number in the vendor account.

• The G/L expense account (or the expected account) shows no line items or no balance.

• The trial balance does not reflect the expected expense.

The first lesson is the most important one: "GL stays empty" is a symptom, not a diagnosis. At least a dozen different root causes can produce it. A good consultant does not guess. A good consultant narrows the problem down in a logical order.

Most learners are taught a simple story: you post a vendor invoice, the system debits an expense account and credits the vendor. That story is true, but it hides several important details.

In S/4HANA, the vendor is posted to a reconciliation account in the General Ledger. The vendor sub-ledger and the G/L are, in principle, one consistent source of truth through the Universal Journal (table ACDOCA). So if a document is truly posted, the G/L should reflect it.

That is exactly why this incident is so puzzling. If the Universal Journal holds the truth, how can the vendor show an invoice while the G/L looks empty?

The answer is that one of three things is usually happening:

1. The document is not what you think it is. It may be parked, held, simulated or blocked, not truly posted.

2. The posting went to a different account, ledger, period or company code than expected.

3. The report you are using is not showing what you think it is showing. This is a filter, selection or authorization issue rather than a posting issue.

Every step of the investigation below tests one of these three families of causes.

Step 1: Confirm the Document Is Really Posted

Before touching configuration, open the document itself. Use transaction FB03 (Display Document) or the Fiori app for displaying journal entries, and enter the document number, company code and fiscal year.

Look at three things.

Document status. Is it a posted document, or a parked document that only looks like an invoice? Parked documents (created with FV60, for example) are saved but do not update the ledger. Held documents behave the same way. A parked invoice can appear in worklists and even be mentioned by users as "posted," but it has no ledger impact until someone completes it.

Document type and reference. Check whether the document came from a supplier invoice in logistics (MIRO) or from a direct FI posting (FB60). This matters for the next steps.

The line items. Open the document and look at every line. This is where many incidents solve themselves. You may discover that the debit did not go to the account the AP team expected.

Real-world example

A learner in a training lab once raised this exact ticket. After opening the document, the debit was on a GR/IR clearing account, not on an expense account. The AP team was looking at the expense account and finding it empty. The system was behaving correctly. The invoice was against a purchase order with a goods receipt, so the expense was recognized at goods receipt and the invoice simply cleared the GR/IR account. No expense was supposed to appear at invoice time.

This single discovery solves a large share of real tickets. And you can only know it if you understand the integration between Materials Management and Finance, which is why a strong course teaches the end-to-end procure-to-pay flow instead of treating AP in isolation.

Step 2: Check Whether It Is a PO-Based Invoice

If the invoice was entered through MIRO against a purchase order, the accounting depends on the account determination logic in MM, driven mainly by the valuation class, the movement type and the transaction keys such as those maintained in OBYC.

For a PO-based invoice, the typical posting is:

• Debit GR/IR clearing (for goods already received), or debit an expense account (for services or non-stock items without a goods receipt, depending on account assignment).

• Credit vendor reconciliation account.

• Tax lines to input tax accounts if applicable.

If the AP lead expects an expense posting but the item is a stock material, the debit will not hit an expense account at all. It will hit the GR/IR account, and the stock or expense was already booked when goods were received.

Ask yourself:

• Was there a goods receipt before the invoice?

• Is the item stock, consumable or service?

• What is the account assignment category on the PO line?

These three questions explain a great number of "missing G/L posting" complaints.

Step 3: Look at the Universal Journal Directly

If the document is posted and the lines look correct, the next move is to see what the Universal Journal says. In S/4HANA, ACDOCA is the central line item table that contains the posting from all ledgers.

Using the display tools in your system, such as a data browser or the Fiori app for journal entries, you can filter by:

• Company code

• Fiscal year

• Accounting document number

• Ledger

Compare what you find with what the report is showing. This is the moment when many learners have their first real insight about S/4HANA: the reports are views on the journal, so if the journal has the entry, the issue is almost always in the report selection, not the posting.

Look for these clues in the ACDOCA records:

• Which ledger holds the entry? The leading ledger (for example 0L) normally holds everything, but entries made in a non-leading ledger only appear when that ledger is selected in the report.

• Which posting period and fiscal year? The posting date might be in a different period from the one the controller is reporting.

• Which account? The G/L account on the line may not be the one the user expects.

• Which currency type? If the report shows a currency type that was not populated, amounts may appear missing.

Step 4: Check the Report Selection Before Blaming the System

This is the part many courses skip, and it is where real consultants save hours.

When a report shows an empty G/L account, check:

Ledger selection

If your company uses parallel accounting (for example, IFRS in the leading ledger and local GAAP in a non-leading ledger), reports must be run for the correct ledger. A posting made only to a specific ledger group will not appear when you run the report for another ledger.

Fiscal year and period range

A surprisingly common cause is a simple one: the invoice has a posting date in the next period, or even a different fiscal year. The report is run for the current period, so the entry is not in range. Always compare the document date, posting date and posting period. They are three different things, and mixing them up creates a lot of confusion.

Company code and chart of accounts

If the user is running the report for the wrong company code, the account will appear empty. This is common in organizations with many company codes and shared charts of accounts.

Line item display settings

For G/L accounts, check whether line item display is activated in the account master data. If it is not, the line items cannot be displayed in the line item report, even though balances exist. Open item management is a different setting and affects clearing behavior, not only display.

Authorization

Sometimes the data is there but the user does not have authorization to see certain company codes or accounts. The report then looks empty, and the system does not always make it obvious. Compare the user's authorizations with another user who can see the data. This is a small test, and it solves the ticket in seconds when it is the cause.

Step 5: Investigate Reconciliation Accounts

A vendor reconciliation account is a special type of G/L account. You cannot post to it directly in normal G/L postings. It is updated through the vendor sub-ledger.

In older systems, reconciliation accounts could show only totals while line items lived in the sub-ledger. In S/4HANA, the Universal Journal brings the details together, but users trained on the old behavior still sometimes believe the account should be empty or look different.

If the AP team says "the G/L is empty," ask which G/L account they are looking at. If they are checking the expense account, we are in the GR/IR or account assignment scenario. If they are checking the reconciliation account, we are in the report selection or authorization scenario.

Asking this one clarifying question is a professional habit. It reflects what we call ticket discipline: never start fixing until you know exactly what the user is looking at.

Step 6: Check for Special G/L Indicators and Alternative Reconciliation Accounts

If the vendor line used a special G/L indicator, such as a down payment request or a bill of exchange, the posting does not go to the normal reconciliation account. It goes to an alternative one defined in the configuration.

So the user may be looking at the normal vendor reconciliation account and seeing nothing, while the amount sits on the alternative account. The fix is not to change the posting. The fix is to show the user where to look and, if needed, update the report or reconciliation procedure.

This is a great example of why you must know the configuration, not just the transactions.

Step 7: Rule Out Technical Posting Issues

If everything above checks out and the data still looks inconsistent, we move to technical causes.

• Update terminations. If a posting was started but the update failed, the user may see a message at the time, but a rushed user may not notice it. Check the update monitoring tools such as SM13 for terminated updates.

• Interface or batch postings. If the invoices came from an external system through an interface or a batch job, check the job logs and the interface monitor. Partial failures can leave some documents created and others not.

• Custom enhancements. A user exit, BAdI or custom code may alter the account assignment or block parts of the posting. If the issue started after a transport, review recent changes.

These causes are less common than the earlier ones. That is why the sequence matters. You always check the simple and frequent causes first, then the rare technical ones.

Step 8: Check Blocks, Workflow and Release Strategies

In some companies, invoices are subject to approval. A blocked invoice, or one stuck in a release workflow, may exist in the system but not be fully processed.

For PO-based invoices, check:

• Payment block or invoice block reasons (price variance, quantity variance, and so on).

• Release status if invoice release is used.

A blocked invoice is not always an unposted invoice, but the business impact can be similar. The team may think "posted" when a block is still holding the process.

9. The Decision Tree: Your Troubleshooting Map

Here is the investigation in the order a seasoned consultant follows it.

1. Clarify the expectation. Which account, which company code, which period, which ledger?

2. Open the document. Is it posted, parked or held?

3. Read the line items. Did the debit go where the user expected?

4. Identify the invoice type. PO-based (MIRO) or direct FI (FB60)? Is GR/IR involved?

5. Check the Universal Journal. Does the entry exist, and in which ledger, period and account?

6. Check report selection. Ledger, period, company code, currency type, line item display.

7. Check authorizations. Can the user really see the data?

8. Check special G/L and alternative reconciliation accounts.

9. Check technical posting issues. Update terminations, interfaces, custom code.

10. Check blocks and workflow.

Notice that nine out of ten of these checks require no configuration change. This is why experienced consultants resolve many incidents in minutes while beginners spend hours.

10. Fixing the Problem: What Do You Actually Do?

Once you find the root cause, the correction depends on the scenario.

If the document was parked: complete and post it, subject to approval and period status.

If the debit went to GR/IR: explain the accounting flow to the AP team. No correction is needed unless the PO account assignment was wrong, in which case you coordinate with procurement.

If the posting went to the wrong account: use the correct process. Reverse the document if allowed, or post a correcting entry. Never edit posted financial documents in an uncontrolled way. Respect the period status, and involve the controller if the period is closed or nearly closed.

If it was a report selection issue: guide the user, and consider creating a saved variant or a Fiori tile with the correct defaults.

If it was an authorization issue: raise it through the security process. Do not simply grant broad access to make the problem disappear.

If it was a technical failure: reprocess carefully and check for duplicate documents before repeating any posting.

Always document what happened. A short root cause note is as valuable as the fix.

Preventing the Next Ticket

Strong consultants do not just close tickets. They reduce future tickets.

• Train users. Explain the difference between expense and GR/IR postings in simple language and with examples.

• Create standard report variants. Save selection variants for common reports so users do not forget the ledger or period.

• Add validations. Use validation or substitution rules when the business needs strict control over account assignment.

• Monitor interfaces. Set up alerts for failed batch postings.

• Review account determination regularly. Especially after new material types or valuation classes are introduced.

• Build a close checklist. Include a reconciliation check between the sub-ledger, GR/IR and the P&L accounts.

11. What This Incident Teaches About Choosing an Online Course

The incident above touches Financial Accounting, Accounts Payable, Materials Management integration, the Universal Journal, ledgers, authorizations and technical monitoring. No single module explains it. This is what real SAP work looks like.

When you evaluate a top-rated SAP S/4HANA FICO online course, ask whether it prepares you for this reality. Here are the questions to ask.

Does the course teach integration, not just modules?

A course that teaches GL, AP, AR and asset accounting in separate boxes will not prepare you for a ticket that crosses three boxes. Look for training that follows complete flows, such as procure-to-pay and order-to-cash, from the business event to the ledger.

Does it explain the Universal Journal properly?

The Universal Journal is the heart of S/4HANA Finance. If a course mentions it only in one slide, you will struggle with real incidents. You should understand what ACDOCA holds, how ledgers work, and how reports read from it.

Does it use incident-based labs?

The best way to learn troubleshooting is to troubleshoot. A good course gives you a broken scenario and asks you to find the cause. Examples include a vendor invoice with no visible G/L impact, a payment run that skips invoices, or a trial balance that does not reconcile.

Does it teach the diagnostic method, not just the answer?

The goal is not to memorize that GR/IR is the cause of this ticket. The goal is to learn the method: clarify, verify, narrow down, confirm, fix, document, prevent. That method works on tickets you have never seen before.

Does it include Fiori and the new S/4HANA tools?

Modern S/4HANA projects rely heavily on Fiori apps for journal entries, balances and line items. A current course should show both the classic transaction codes and the Fiori equivalents, because real projects use a mix.

Does it give you trainer access and real feedback?

Troubleshooting skill grows through discussion. You need a trainer who can review your approach, challenge your assumptions and share real project stories.

Does it prepare you for interviews?

Many SAP interviews are scenario-based. Interviewers ask questions like, "A vendor invoice is posted but the expense account shows nothing. What do you check?" A candidate who answers with a structured method stands out immediately.

12. Why ProExcellency Is the No.1 

Here’s why ProExcellency Solutions is continuously in :

• Certified Trainers with 10+ years of experience

• one hundred % Practical-Oriented Learning

• Flexible Online & Weekend Batches

• Training Projects and Case Studies

• Affordable Fee Structure

• Placement & Resume Support

• High Success Rate in Certification Exam

13. Practice Scenarios to Try

If you want to build this skill, try these variations in a sandbox or training system.

1. Park an invoice and then search for it in the G/L. Observe what appears and what does not.

2. Post a PO-based invoice after a goods receipt. Trace the accounts used in the goods receipt and in the invoice.

3. Post an invoice for a service PO with account assignment to a cost center. Compare the result to the stock material case.

4. Run the same G/L report for two different ledgers. See how parallel accounting changes what you see.

5. Post with a posting date in the next period. Run the report for the current period and find the entry.

6. Use a special G/L indicator for a vendor down payment. Find which reconciliation account was updated.

7. Remove a test user's authorization for one company code. See how the report behaves.

Each scenario reproduces one cause from the investigation above. After practicing all seven, you will recognize the pattern immediately in a real project.

14. Common Mistakes Consultants Make

• Jumping to configuration changes. Most of the time, nothing is misconfigured. The system is doing what it was configured to do.

• Not asking the user what they are looking at. Half of the tickets are solved by one clarifying question.

• Ignoring the period and ledger. These two filters cause a large number of false alarms.

• Correcting postings without controller approval. Financial corrections have audit consequences.

• Not documenting. If you solve it once and do not write it down, you will solve it again next quarter.

• Blaming users. Good consultants educate and improve the process without making users feel foolish.

Think Like a Problem Solver

The phrase "vendor invoice posts but the GL stays empty" sounds like a technical question. In reality it tests how you think.

Can you stay calm when a controller is waiting? Can you ask good questions? Can you follow a logical path from the document to the ledger to the report? Can you explain the answer in simple business language?

These abilities are what make a consultant valuable, and they are exactly what a top-rated online course should develop. Configuration knowledge gets you started. Problem-solving skill gets you trusted.

Final Thoughts

The next time someone says the G/L is empty after an invoice posting, remember that the system is rarely broken. Usually, either the document is not what it seems, the posting is somewhere unexpected, or the report is not showing what the user thinks it is showing. A structured approach will find the answer quickly.

If you are choosing an SAP S/4HANA FICO online course, pick one that treats incidents like this as core training material. Look for integration-focused lessons, hands-on labs, Universal Journal depth, Fiori coverage and a trainer who teaches the thinking process behind every fix. Because on your first day in a support role, nobody will ask you to recite a configuration path. They will ask you a question like this one, and they will expect you to solve it.

Blog Written By C.RojaRani