Within the previous posts on vendor prepayments the major focus was on tax issues and how to ensure that they are posted correctly when recording vendor prepayments.

In this post I would like to focus on the disclosure of prepayments in a company’s balance sheet and the differentiation between requested and paid prepayment amounts.

That is, at the time vendor prepayment invoices are recorded in AX they do not constitute a right/receivable against the vendor who sent the prepayment invoice, as no exchange of goods/services occurred.

The right (receivable) that your company has against the vendor arises at the time when the payment to the vendor is actually made.

For that reason, some companies prefer separating “requested vendor prepayments” – that do not establish a right against your vendor – from “realized” vendor prepayments that constitute a legal claim against your vendor, as the prepayment invoice has been paid.

Problem:
The problem with the separation of requested from actually made vendor prepayments is that Dynamics AX does not provide a functionality that automatically generates a corresponding voucher at the time the prepayment is made. The following illustration that is based on the examples used in the previous posts explains the issue.

What you can identify from the illustration above is that an additional ledger transaction that debits the vendor prepayment account and credits the requested vendor prepayment account is required at the time when the payment of the prepayment invoice is made.

As the standard Dynamics AX features do not support the required Transaction, you can either implement a system modification or use one of the following workarounds.

Workaround (1):
A first option for separating requested from made prepayments is creating a manual General Ledger entry based on an inquiry of the prepayment transactions recorded. The following example demonstrates this procedure.

Example:
For the following illustrations, three purchase orders with prepayment amounts of 5000 EUR (5950 EUR), 2000 EUR (2380 EUR) and 6000 EUR (7140 EUR) are recorded in Dynamics AX. (Note: the amounts included in brackets represent the gross prepayment amounts incl. 19% VAT).

The prepayment invoices are recorded as described in the second post on vendor prepayments by using two service items (“ANZ” and “ANZVERR”) as illustrated in the next screenshot.

Please note that the service prepayment items (“ANZ” and “ANZVERR”) are setup with their item number as financial dimension value.

Also note that the ledger setup of the first service item differs from the earlier posts and does now refer to the requested prepayment account no. 132201.

The next screen-prints shows the prepayment invoice amounts posted together with the corresponding amounts that have been paid to the vendor.

Against the background of this summary and the transactions recorded in AX, 6000 EUR need to be transferred from the “requested prepayment” account No. 132201 to the ordinary prepayment account No. 132200. The amount that needs to be transferred can be identified from the sum of the ledger accounts 130850, 132201 and 200100 filtered by the “ANZ” item financial dimension. The next screenshot shows the necessary (manual) ledger transaction that needs to be posted.

Result:
After posting the manual prepayment transfer, the trial balance list page shows the following data:

In the previous screenshot, the lines highlighted in blue color represent the prepayment invoice payments made to the vendor (6000 EUR net + 1140 EUR VAT = 7140 EUR) that allow a VAT deduction of 1140 EUR. The lines highlighted in yellow color represent the prepayment invoices posted but not paid. For that reason, the VAT related to those invoices cannot be deducted yet.

Workaround (2):
If you do not like creating manual journal entries, you can setup an allocation rule as shown in the next screen-prints that does the calculation and posting job for you.


The outcome of the second workaround that uses the allocation rules for making the transfer postings is of course identical to the one realized via the first workaround. Yet, the second workaround allows you repeating the allocation transaction as often as required with almost no effort required.

This post concludes (for now :-)) the posts on vendor prepayments. I hope you enjoyed the series and look forward to seeing you in the next posts.