If you've ever wondered about the intricate mechanisms behind processing down payments in SAP as eDocuments, or perhaps questioned why only the F-39 transaction is supported and not F-32, then this blog post is tailor-made for you.
Understanding Prepayments
Let's begin by unpacking the definition of prepayment from ZATCA (Zakat, Tax, and Customs Authority), a body that defines e-Invoicing regulations in the business context. Essentially, a prepayment is a sum of money paid upfront by a purchaser to a seller for goods or services prior to their full delivery or performance. It's a common practice employed to secure the delivery of goods or services and demonstrates a buyer's commitment to the transaction.
The Making of an eDocument
In SAP, when a customer downpayment document is composed in F-29 (with or without a down payment request reference), an eDocument, depicting an invoice, is created in the cockpit. The system categorizes this as a downpayment document utilizing the special GL indicator maintained in the DOWNPAYMENT_GL_IND value mapping.
F-39 vs. F-32 Transactions
The principal difference between the two lies in their functionalities. F-39 serves as a definitive transaction to reconcile downpayment documents with an invoice. Essentially, you can utilize this transaction to reconcile any number of downpayment documents, but only with a single invoice number at one time.
On the contrary, F-32 operates as a customer clearing transaction, allowing multiple invoices to be reconciled with numerous downpayment and normal payment documents.
Adhering to the ZATCA Regulations
According to ZATCA guidelines, details about the downpayment document and its specifics should be provisioned in the corresponding invoice XML when these downpayments are categorized as prepaid or advance payments.
Required Prepaid Document Details
There are several key details required by ZATCA when referring to a downpayment (prepayment) document in an invoice.
- Pre-Paid amount (Advance Received):
Refers to the funds paid by a buyer to a seller for goods or services before they are fully delivered or provided. It's essentially an upfront payment meant to secure the provision of the said goods or services.
When the prepayment amount is reported in the totals section (LegalMonetaryTotal) of the XML, it is mandatory to report the below details as line items of the invoice.
- Document Reference: This is the downpayment document number.
- Issue Date: This is the date when the document is created.
- Issue Time: This is the time when the document is created.
- Document Type Code: This is always 386 (down payment documents).
- Taxable Amount: The total Downpayment (DP) amount excluding tax used in clearing an invoice.
- Tax Amount: Tax amount of the base Downpayment (DP) amount as per the tax category and tax rate reported in this line item.
- Tax Category: Tax category as per ZATCA specification that you maintained in the value mapping -TAX_CATEGORY.
- Tax Percent: Tax percentage according to the VAT code maintained in the document.
- Item: Static item text as “Prepayment adjustment”.
Please note, every line item of the source down payment document number that is referred during clearing is reported as a different line item in the XML.
The Limitation of F-39 and F-32 Transactions
F-39 is a blessing for its simplicity. It allows us to refer to one invoice to clear multiple downpayment documents, either partially or fully. This means referencing these downpayment documents in XML is straightforward and easy—no sweat there.
But with F-32, things get a tad more complicated. It’s when invoices get intertwined with multiple downpayment documents and non-downpayment documents that things start to blur. The link between the invoice and down payment documents doesn’t get established - it's like trying to solve a jigsaw puzzle with missing pieces!
For instance, when examining a transaction, we can't identify which down payment document was used to clear which invoice. What we do know is only how much of the total amount was cleared, but not the 'who' and 'how' of the clearance equation.
Moreover, the F-32 code cannot distinguish between the cleared non-downpayment document amounts from the cleared downpayment document amount for a specific invoice. The inability to segregate these amounts is a notable limitation of the F-32 transaction.
With these challenges, it's no wonder that the F-39 code is the go-to transaction for clearance of downpayment documents in KSA eInvoicing solutions. So if F-32 has you in knots, remember, F-39 might just be your problem-solver.
Let's dive a bit deeper to comprehend why F-32 might not be the best option for down payment clearing. To simplify things, consider this scenario:
You've a range of invoices and down payments to clear. Invoice 1 is for the amount of 2300, but you only need to clear 1700. So, the dilemma arises: Did you use 1400 from Document of downpayment (DP1), 200 from DP2, and rest as final payment? Or did DP2 contributed just 100 and final payment cover the remaining 200?
The waters get murkier with Invoice 2 for 3450, needing just 100 to clear. Did it come from DP1 or DP2?
Here's a simple layout of this scenario:
Document type Document amount Selected amount for clearing Source?
| Invoice 1 | 2300 | 1700 | DP1 - 1400, DP2 - 200, Final payment – 100 or DP2 - 100, Final payment - 200? |
| Invoice 2 | 3450 | 100 | DP1 - 100 or DP2 - 100? |
| DP1 | 1500 | -1400 | |
| DP2 | 200 | -200 | |
| Final Payment | 200 | -200 | |
This example clearly illustrates the inherent ambiguity that comes with using the F-32 transaction.
With the F-32 transaction, the relationship between the invoices and the down payment documents isn't clear, making the financial recording a smoky affair. Not to mention, it leads to further complications in reporting the cleared downpayment amount, prepaid amount, and other essential details in the XML.
In Conclusion:
Given these complexities, we strongly recommend using the F-39 transaction for clearing downpayments instead of F-32. It simplifies the process and ensures compliance with the reporting of prepaid details in invoice XML. "For striving towards financial transparency and effective reporting of downpayments in your eInvoicing journey, F-39 stands as your invincible ally."
Thanks for being an integral part of our reading community. Your participation inspires us to keep researching and sharing these insights. Looking forward to our next enlightening discussion. Until then, happy reading
Other blogs on KSA eInvoicing
Solution onboarding guide
Master data mapping in KSA eInvoicing solution | SAP Blogs
One time Customer transactions in KSA eInvoicing | SAP Blogs
Handling Intercompany transactions in KSA eInvoicing | SAP Blogs
Some useful links
Note: For accessing the last three links listed above you need to login to MENA Localization SIG – Overview (sapjam.com)
