(No, of course I don’t expect everybody to get the pop culture reference, that’s okay)
This blog post’s aim is to provide the definitive answer to the age-old issue of the limitation of SAP’s BSEG table to 999 items per document and the infamous error message F5 727 (“Maximum number of items in FI reached”), with one very important prerequisite: you’ll have to have entered the SAP S/4HANA world. So, if you’re still on ECC and have never heard of the ACDOCA table (aka the Universal Journal), I’ve got some sad news for you: you can stop reading right here – sacrifice is still going on tonight; for all the others: you have te fire and you have the force!
Now, as the more perceptive of you have probably realized by now (sorry, no offense, just another pop culture reference, the last one, I promise), the classical FI document item table BSEG has a technical limitation and this is the three-digit item number field BUZEI, which means that it can only store up to 999 items per document. So, in R/3 and in ECC, this was and is quite a source of major headaches, since BSEG was and is the one and only “FI truth”. Yes, some twenty years ago SAP introduced the NewGL (New General Ledger) with its line item table FAGLFLEXA, but even this NewGL line item table was never updated separately (at least for the leading ledger), there was always the BSEG with this limitation in the background, too.
In SAP S/4HANA, this situation has changed radically, since the many “accounting truths” (table BSEG as FI truth, COEP as CO truth, ANEP as FI-AA truth, MLIT as Material Ledger truth, etc. etc.) were merged into one and only one accounting single source of truth: the table ACDOCA, the Universal Journal.
What does this mean for the BSEG table in SAP S/4HANA? I have seen all kinds of statements on the internet, ranging from “nothing has changed in SAP S/4HANA, BSEG is still being updated, the 999 restriction still holds, shame on SAP!” to others getting it exactly right (“Yes, BSEG is still updated, but…”) to statements in the middle ground (“ACDOCA is great, but it’s a pity that SAP forgot to include each and every BSEG field into ACDOCA (e.g. payment terms), so we still need BSEG”).
The simple truth is: yes, BSEG is still there in SAP S/4HANA, but it has changed its nature! It used to be both the Financial Accounting document and the Financial Operations line item, but in SAP S/4HANA it’s only the Financial Operations line item.
BSEG vs. ACDOCA in S/4HANA: FIN Operations vs. FIN Accounting
Please allow me to provide some background: At SAP, for over twenty years we have distinguished (at least in our minds) between “Financial Operations” and “Financial Accounting”.
- The first term means real world stuff you need to do when you’re running a business: paying your suppliers, receiving payments from your customers, clearing open items, sending out dunning letters to your defaulting debtors, recording and paying taxes to your tax authority, but also manually posting financial documents using classical transactions such as FB01 or the Post General Journal Entries Fiori app.
- The second term refers to some sort of “virtual” layer on top of the real-world operations: transforming the logistical and operational business transactions into accounting records by assessing and valuating them according to different accounting principles / charts of accounts / fiscal year variants etc., maybe perform a currency conversion into local or functional currency, sorting them in into different ledgers (with potentially differing values), and thus provide the accounting records for both legal and management financial reports like balance sheet / P&L statement etc.
A helpful analogy might be the economic distinction between nominal and real values, the first representing just “plain money” whereas the second includes a valuation step – adjusted for inflation or purchasing power.
Anyway, this is exactly how we see the difference between BSEG and ACDOCA in SAP S/4HANA. BSEG represents the “Financial Operations” line item, ACDOCA the “Financial Accounting” line item. In R/3 and ECC, BSEG was both! But in SAP S/4HANA, we reduced BSEG’s importance, so that it just represents the Financial Operations item (yes, it’s a downgrading for poor old BSEG, and I hope Hasso never gets to read these lines); we need it as a hook for paying, clearing, taxes, and as a document entry view for manual financial postings. But it’s not the Financial Accounting document item anymore, this is what ACDOCA is now.
With this distinction in mind, you maybe understand why we didn’t just extend the BSEG-BUZEI field to six digits: because BSEG is not the Financial Accounting document anymore, it’s by and large just an open item registry, so it should never carry so many items per document. Or why we didn’t include all BSEG fields (e.g., payment terms ZTERM) into ACDOCA: ACDOCA is not a 1-1 replacement of BSEG, it just replaces its accounting aspect; operational stuff like payment terms don’t belong in accounting.
What are the implications of this significance shift of BSEG’s role? It follows naturally that you can now radically reduce the number of BSEG items of a document by summarizing its non-operational items.
Please let me stress that deleting accounting information from BSEG in order to summarize (compress) the BSEG items and thus get well under the 999 threshold is not a “workaround” from SAP (I have read this statement, too, on the internet). It is the way to go in SAP S/4HANA! A few years ago, we seriously discussed the idea of extending the BSEG-BUZEI field but decided that this would be the wrong architectural direction for the future.
BSEG summarization (compression)
“Please, speak as you might to a young child. Or a golden retriever.” This is a great line (especially when it’s spoken by Jeremy Irons) from the (also great) 2011 movie Margin Call, and it’s a terrific advice, since explaining a somewhat complex topic in the simplest possible way helps not only the audience, but most importantly helps the speaker to get to the essence of the issue. Following this golden (retriever) rule, here’s a very simple example to explain the BSEG summarization and the relationship between the BSEG view and ACDOCA view of an outgoing invoice.
Assume you’re a brewery supplier producing different sizes of beer bottles and bottle caps for brewing companies. You were ordered to make a bunch of 0.33-liter bottles, a bunch of 0.5-liter bottles, and a bunch of bottle caps for some brewery called ‘Holly Dyver’. Then the ACDOCA view of your invoice would look like this (for the sake of simplicity, we ignore ACDOCA document splitting here – where the AR and the tax items might be split according to the profit centers of the sales revenue lines):
ACDOCA view
G/L account | Customer | Article | Amount |
140000 (AR domestic) | HOLLY DYVER | | USD 1000,- (Debit) |
175000 (Output tax) | | | USD -200,- (Credit) |
800000 (Sales domestic) | | BOTTLES 0.33 l | USD -300,- (Credit) |
800000 (Sales domestic) | | BOTTLES 0.5 l | USD -400,- (Credit) |
800000 (Sales domestic) | | BOTTLE CAPS | USD -100,- (Credit) |
The first line is your Accounts Receivable (AR) line (the open item you need to clear once the invoice is paid by the brewery), so we need it in BSEG, the second line is the VAT line, so we need it in BSEG, too, but the three sales revenue G/L lines could be summarized (compressed) in BSEG by deleting the article information (BSEG-MATNR), yielding this BSEG view of the invoice:
BSEG view
G/L account | Customer | Article | Amount |
140000 (AR domestic) | HOLLY DYVER | | USD 1000,- (Debit) |
175000 (Output tax) | | | USD 200,- (Credit) |
800000 (Sales domestic) | | | USD 800,- (Credit) |
5 ACDOCA items vs. 3 BSEG items. The article BSEG-MATNR is gone from the BSEG, but this doesn’t matter at all, since you have it on the ACDOCA, which is the Financial Accounting document, the Universal Journal, the single source of truth for all your accounting reporting.
Now imagine that instead of invoicing for three articles, the invoiced contained one thousand articles (or sales order items, for that matter). In the same way, this would lead to 1002 ACDOCA items (1 AR, 1 VAT, 1000 sales revenue), but only 3 BSEG items (1 AR, 1 VAT, 1 sales revenue).
So please remember just three things from this outgoing invoice example:
- The only items we need in BSEG are the AP/AR lines + the tax lines. The offsetting G/L lines we don’t really need – we just need a summarized view of them to make this transaction balancing on the BSEG (you could also call it a “skeleton” BSEG). The ACDOCA keeps all the accounting relevant information.
- You don’t need any account assignments like cost center or profit center or profitability segment in the G/L lines, since you have them on the ACDOCA!
- By deleting information from BSEG you can get well below the 999 limit.
BSEG update suppression
While the BSEG summarization (compression) is the way to go for all accounting related transactions in SAP S/4HANA, there are certain transactions where we can go one step further: Whenever there is nothing “FIN operational” involved in the posting (so no AP/AR lines, no tax lines, no open item managed G/L accounts), we can actually suppress (skip) the updating of the BSEG table without a wince! Again, don’t be afraid, be brave, the situation is different in SAP S/4HANA, you have the ACDOCA table. Since the beginning of SAP S/4HANA, we had accounting processes which don’t update the BSEG at all, e.g. CO internal repostings or G/L foreign currency valuations. In the meantime, other processes have joined the club, such as G/L allocations or asset depreciations.
For the techies: you can identify those accounting documents without BSEG update using the BKPF-BSTAT (or ACDOCA-BSTAT) field; they have the value ‘U’ in the BSTAT field.
When you display such a document, you will be immediately routed to the “General Ledger View”, there will be no “Entry View”, this is all. And for such a document we obviously don’t have a 999 restriction anymore since this restriction only applies for the BSEG table.
Think of some pure G/L balances transferred to S/4HANA in a BAPI (where all the operational stuff is already done in the source system), some pure G/L valuation postings or some MM postings like stock transfers, goods issues, or outbound deliveries. There’s no customer/vendor involved here, no taxes, no open item processing, so BSEG update can safely be skipped.
With this in mind, we come to the most important part of this blog post, the practical one.
How to avoid the “maximum number of FI items reached” error
How can you achieve the summarization or even the update suppression of BSEG, so you can avoid the “maximum number of FI items reached” error?
We have a SAP FAQ note for SAP S/4HANA which is the 2591291 - FAQ S/4HANA: Error F5 727 when posting via Accounting Interface (I encourage you to read it), where the three different options (called “lines of defense”) are described.
BUT: I want to make clear here that the third line of defense (the splitting of the big documents into several smaller documents containing 990 lines) should not be necessary anymore, that’s why I don’t even mention this option in this blog post.
Furthermore, our evaluations show that some of our SAP customers even struggle with the most important line of defense (the traditional BSEG summarization customizing transactions OBCY and OBCYX), because this (field based) customizing seems to be too cumbersome to maintain.
BSEG summarization / suppression made easy by BAdi
For this reason, we decided to offer a new BAdi BADI_FINS_SUMMARIZE_BSEG, which is basically a convenient replacement of the old customizing transactions OBCY and OBCYX, but it goes one step further: you can simply say “summarize BSEG to the max” (depending on the document origin), then all non-relevant fields will be cleared from the BSEG. As a next step, we plan to even make it one louder, turn it up to eleven, so you can also try to totally skip the BSEG update in a second method by just setting one parameter “suppress if possible”. The system will check if the preconditions for BSEG update suppression are met (see above), if yes, BSEG update will be skipped. This BSEG update suppression BAdi method is not active yet, but the plan is to activate it soon. The new BAdi is presented and described in SAP note 3334910 – BAdi BADI_FINS_SUMMARIZE_BSEG and we’ll keep you updated in this blog as well as in this consulting note.
What about Public Cloud?
While all I said so far applies to both SAP S/4HANA On-Premise / Private Cloud edition and SAP S/4HANA Public Cloud edition, the BAdi BADI_FINS_SUMMARIZE_BSEG is a pure On-Prem / Private Cloud BAdi. In the Public Cloud edition, we have already implemented an effective BSEG summarization for outgoing invoices. But we wanted to improve the situation here, too, so what we did with CE 2402 is offer these two flags “Maximum Summarization” and “Suppress if Possible” in a configuration UI (SSCUI ID 106716)! Here’s the link to the corresponding CE2402 What’s New documentation. In the Public Cloud edition, we don’t have the compatibility issues we have in the on-premise world (think of lots of old custom ABAPs selecting BSEG) which might prevent SAP customers from implementing the maximum summarization or trying out the suppress option immediately. That’s why we push this feature more aggressively into the Public Cloud edition. With CE 2408, the plan is to make these two options the default for new installations.
Other things to consider
Just to mention some annoying (slightly wonkish) details:
- It sort of goes without saying that your accounting reporting should be based on ACDOCA (not on BSEG). This is a somewhat banal statement in SAP S/4HANA, but it’s now essential if you summarize and/or suppress the BSEG update. Particularly, for displaying G/L account balances transaction FAGLB03 should be used (rather than transaction FS10N), FAGLL03 (or the line item browser FAGLL03H) for displaying G/L account line items. If you still rely on some custom BSEG based accounting reporting (Z-ABAPs), you should adapt these ABAPs so they read ACDOCA rather than BSEG. (SAP note 2431747 - General Ledger: Incompatible changes in S/4HANA compared to classic ERP releases gives you some background on this topic.)
- When displaying a document via transaction FB03, you should focus on the General Ledger view (not the entry view). You can make FB03 display the G/L view first by an accounting editing option (transaction FB00).
- A prominent example of a process which can lead to the 999 limitation is the automatic clearing of GR/IR clearing accounts. To overcome this, we developed a new feature Extended Open Item Management (FAQ) with SAP S/4HANA 2021. The GR/IR accounts clearing will then be based on ACDOCA (not on BSEG), no 999 limitation any longer.
- If you activate the “suppress if possible” option in the BAdi, some BSEG based business transaction events (BTEs) will not be processed any longer (to be precise: the BTEs 1120, 1130, 1025, and 1050). If you happen to have implemented one of these BTEs (which is very unlikely, though), you should reconsider this
- The changing of line item fields (such as the text field SGTXT) of a posted document with BSEG update suppression (via transaction FB02 or the Manage Journal Entries Fiori app) is currently not possible. We are working on a feasible solution here.
Executive summary
There is exactly one key takeaway I want you to remember from this blog post:
The 999 items limitation (and thus the “Maximum number of items in FI reached” error message) is solved in SAP S/4HANA, it’s not an issue any longer. (Don’t tempt me to continue all the way: it has ceased to be, it’s kicked the bucket, it’s pushing up the daisies, it’s joined the choir invisible…)
There should be nothing to prevent you from summarizing – or even suppressing – the BSEG update, getting you well below this threshold. And the summarization + suppression is the solution in SAP S/4HANA, it’s not a workaround.
And while the devil’s always in the details (note 3334910 mentioned above lists some of these), this is the big message I want to bring across to you.
Keep on rocking and up the irons!
