Money Up Front: Prepayments in Microsoft Dynamics NAV 5.0

In a lot of business contracts, you’ll find that payment either in full or partial has to be made before the order is handed over to fulfillment. Like in ordering imported items, made-to-order items, or simply when a customer has no previous record with the selling company.

On way of creating the proper documents for this is to create an invoice for the advance payment, and then remember to deduct it when the order is fulfilled and final invoicing is taking place. Common practice, but also one that relies heavily on the user tracking all the documents to an order, relies on someone to check if payments are received before order fulfillment, and one that is prone to errors when the advance payments is deducted on the final invoice.

In 5.0 we’re addressed the advance payment issue with the Prepayments feature. It allows the creation of Prepayment Invoices and it keeps track of the Prepayment Invoices so correct and full deduction can be automatically applied to the final invoice.

Many scenarios can be thought of in relation to advance payments so NAV 5.0 has functionality that allows the user to create a very diverse set of prepayments invoicing scenarios for both sales and purchase orders, including among others setting prepayments % or amounts for individual lines, setting a fixed prepayment amount, and controlling how the prepayment amount(s) are deducted as the order is fulfilled, e.g. when partially invoicing – all aiming at giving the user flexibility enough to accommodate the most common current business practices.

For a first release of a new feature it of course comes with limitations – some due to initial requirements, some due to time and resource scarcity in a release. Some are already being considered for improvement in coming versions. Three of the limitations are:

  • The VAT setup relies on G/L account setup; this was due to the fact that this was intended more as a replacement for doing a manual extra invoice for any advance payments. Requests are that this be modified so it follows the items, e.g. prepayment VAT accounting is based on the specific content of the order.

  • Invoice discounts are not included in the prepayment calculations, due to complexity when tracking multiple prepayment invoices, e.g. when updating an order and sending new prepayment invoice. This limits the scenarios with 100% prepayments combined with invoice discounts.

  • Installments-like prepayments are not possible. There is no planning tool for issuing fixed interval prepayments, e.g. for larger order you could have fixed dates for multiple future advance payments. The Prepayment invoices must be created one by one.

Improvements on this limitation will happen as we gather feedback from market.

Brian Nielsen

Comments (3)

  1. Ian Murphy says:

    With V5.0sp1 you cannot handle the typical:

    – Make an offer to potential client

    – Client accepts offer – you create Job

    – Convert the offer into an order

    – Invoice the order in phases – but booking the costs against the Job (the missing bit)

    This isn’t exactly an unusual situation – pretty much all IT companies work this way – including MS consulting services.

    This is little more than the above turned round the other way.

    Look into handling retentions – used a lot in the construction and engineering industries. Its not complicated – just a faf to have to implement.

  2. Gerard Wullink says:

    Does a payed prepayment result in a Released status of the Order from which the prepayment invoice was created?

  3. Ivan Koletic says:

    Payed prepayment does not result in Released status of the hrder for which Prepayment is created. In prepayment version above and in 5.0 SP1 there's an option to not allow final sales invoice posting unless payments are applied (but it also doesn't impact the order status).

Skip to main content