How to use credit memos to break down your liquidity planning

Energy companies that provide reimbursements for the electricity generated by solar systems and wind farms or companies with many suppliers, e.g. those from the automotive sector and in online trading, now make extensive use of credit memos to make their task easier. But what are the potential pitfalls of this?

In this article, we show you how errors in the creation of credit memos can result in a significant burden on your cashflow and how you can protect yourself from being caught off guard.

Invoices play a particularly important role in VAT law. Missing or incorrect legally prescribed invoice details (Section 14 (4) of the German VAT Act (Umsatzsteuergesetz – UstG)) can lead to the refusal of the input tax deduction by the service recipient and thus by the recipient of the invoice.

With a sales tax credit, the service recipient can also settle the received service with the service provider itself (Section 14 (2) sentence 2 of the German VAT Act (UStG)). In practice, this can occur whenever the service recipient knows the basis of settlement better than the service provider. This kind of settlement must thereby be agreed upon between both parties involved in advance. The special feature of issuing this type of credit memo is that the service recipient provides the conditions for the input tax deduction itself.

Errors in the issuing of the credit memo can lead to the refusal of the input tax deduction.

This can be a painful discovery if it becomes apparent in the course of a tax audit, which as a rule always covers three fiscal years. You may then find yourself exposed to considerable cash outflows to the tax authorities, which you can only counter by correcting these incorrect credit memos.

How does the creation of credit memos work in SAP MM?

The keyword when it comes to sales tax credit memos is “ERS” – “Evaluated Receipt Settlement” or “Automatic Goods Receipt Settlement”.

The ERS is particularly suitable for the periodic, e.g. daily, creation of settlement documents and offers the advantage, among other things, that there is no need for manual invoice verification and that quantity and price variances do not occur in invoice verification. The rough procedure in an MM module can be illustrated as follows:

What does a quick check look like in SAP or in the MM module?

In a first step, the “BKPF” table, which contains the posting document headers, is checked for the “MRRL” transaction with the “TCODE” field. As shown above, sales tax credit memos are generated in SAP with this transaction. The fiscal year (GJAHR), the document number (BELNR) and the document date (BELDAT) are also selected. For the subsequent evaluation, simply use the “DBACOCKPIT” transaction to execute the SQL statements directly in the database using the SQL Editor from the “Diagnostics” category. The SQL statement required to analyze the transaction “MRRL” then looks like this:

SELECT BKPF.GJAHR,BKPF.BELNR, BKPF.BLDAT, BKPF.TCODE WHERE TCODE LIKE 'MRRL'

This result set is enriched by a “JOIN” with information from table BSEG (document segment). The vendor number is required here (field LIFNR). The WHERE clause at the end restricts the results to transactions in which vendor numbers are also stored.

SELECT BKPF.GJAHR,BKPF.BELNR, BKPF.BLDAT, BKPF.TCODE BSEG.LIFNR FROM BKPF
LEFT JOIN BSEG ON (BKPF.MANDT=BSEG.MANDT AND BKPF.GJAHR=BSEG.GJAHR AND BKPF.BELNR=BSEG.BELNR)
WHERE TCODE LIKE 'MRRL' AND BSEG.LIFNR <>''

Finally, a “JOIN” is also used to link the results obtained here to the supplier master data. Here the country of origin of the supplier (LAND1), as well as the tax number (STENR) or the sales tax identification number (STCEG) are necessary. The entire SQL query then looks like this:

SELECT BKPF.GJAHR,BKPF.BELNR, BKPF.BLDAT, BKPF.TCODE, BSEG.LIFNR, LFA1.LAND1, LFA1.STENR, LFA1.STCEG
FROM BKPF
LEFT JOIN BSEG ON (BKPF.MANDT=BSEG.MANDT AND BKPF.GJAHR=BSEG.GJAHR AND BKPF.BELNR=BSEG.BELNR)
LEFT JOIN LFA1 ON (BKPF.MANDT=LFA1.MANDT AND BSEG.LIFNR=LFA1.LIFNR)
WHERE TCODE LIKE 'MRRL' AND BSEG.LIFNR <>''

The query returns the following results for the SAP test system used:

Here it is noticeable that, apart from a single document on the last line, no tax or sales tax identification numbers are stored for all other documents at the present time.

It should be pointed out that a document dated 01/03/2018 (in other words, the document with document number 5100001297 on the first line of the table) is linked to vendor master data at the time the query is executed. This is an indication that master data may be missing.

In our experience, this is a good way to work. A look, for example, at the change documents in the test system for the vendor on the first line (LIFNR T-K515B22) then reveals that a tax number has never been stored for this vendor since it was created. This raises the question of which tax number was printed on the credit memo. The last data record is also conspicuous, if only because of the sales tax identification number “DE99999999999” and thus should also be checked.

Perhaps you do not have the necessary authorization to use the “DBACOCKPIT” transaction or talk of SQL just leaves you plain baffled? – Then why not take a look at zap Audit and schedule an appointment with us, all with no obligation!

In zap Audit, the indicator is called “credit memo with different tax codes” and is structured in the profiles according to the respective document type: