When users post customer or vendor business transactions, they should always consider the process of order matching – application of posted invoices to payments or credit memos. It is generally important, as unapplied entries are treated in accounting as separately receivables and payables. Thus, having both invoice and payment posted in the system without separately applying them to one another will result in discrepancy of accounting books.
For Russian accounting processes it is even more critical. Quite many accounting processes and operations depend on the correctness of application of customer and vendor entries:
- In Russia quite many operations are done via prepayments. Prepayments are booked on separate accounts, and correct application of entries moves the prepayments from those accounts to normal settlement accounts.
- Moreover, when vendor receives a prepayment from customer, a VAT from advance payment should be booked. Thus not applied customer entries will result in non-deducted VAT from advance payment in time, causing negative effect on the cash-flow, as more VAT will be paid to government than needed (https://community.dynamics.com/nav/b/russianerpexperience/archive/2016/01/19/vat-treatments-in-russia-recommendations-to-vat-setup-of-posting-groups-in-erp-systems).
- This gets even worse when there are currency transactions or transactions, nominated in foreign currency (conditional units https://community.dynamics.com/nav/b/russianerpexperience/archive/2016/04/16/conditional-units-russian-alternative-to-currency). Application of invoice to payment results in calculation of currency exchange rate differences. There is also a legislation rule that says that if there has been a prepayment, the consequent invoice should be booked at the rate of the prepayment (in the amount of prepayment). I’ve blogged about that earlier here: https://community.dynamics.com/nav/b/russianerpexperience/archive/2016/06/30/russian-specifics-of-processing-currency-invoices-exchange-rate-differences-and-advance-payments, but the application process exactly is the trigger for that correct posting.
Thus application of entries is a very important and inevitable process.
However manual application usually causes protests from those Russian accountants that got used to work with 1C system, as they usually claim that in 1C the process of application has been fully automated, and Dynamics NAV is not capable to do this automatically, thus they need enormous additional time to do the accounting and close the books.
[perfectpullquote align=”full” bordertop=”false” cite=”” link=”” color=”#fa8d29″ class=”” size=””]It is not so![/perfectpullquote]First of all, the process of manual application of entries in NAV is not that difficult and time-consuming when users learn how to do that and follow this process on a daily basis.
Then, the application itself might not necessarily be done via drilling down to posted entries and selecting them via separate application process. There is always a (good) option to select posted invoice to be applied to payment already in the line of bank financial journal before the posting of daily bank statement transactions, there is a special field for that – the application will take place automatically then.
On the other hand, local 1C accounting system is not that automatic either. There are two ways of handling the transactions in 1C: on contract level and on document level. The “on document level” option means that in each payment order you post in 1C users need to select an invoice(s) that matches this payment order. This process is exactly the same as described just earlier for NAV when posting the bank statement – so basically 1C “on document level” process is exactly the same as NAV process.
Another option of 1C is application of entries “on contract level”. Under this condition, all the entries for the same contract are automatically applied (here “contract” can be seen as a sort of dimension) under FIFO basis, based on the dates of transactions. But, in NAV there is also a setup on the customer/vendor card for fully automatic application of entries (on the Payments pane, in the Application Method field, select “Apply to Oldest” instead of default “Manual”). The entries will be applied automatically.
Here is where the important part is. If transactions are posted not in chronological order, there could be discrepancies (e.g., if the currency invoice is applied to a wrong payment, then wrong currency exchange rate differences will be calculated. In local 1C system there is a special procedure for that which is called “restore the sequence of transactions”. This means when you have posted everything and system automatically applied entries, users can run a batch job that would run through entries and re-apply them the way it matches the chronological FIFO order. This process is not possible in NAV, and once system had applied entries automatically, they are there they way they are applied, and without manual interaction the sequence will not be changed.
As you can imagine, even the batch job that analyzes and restores the FIFO sequence might be finally incorrect as there might be specific payments meant to be applied to specific invoices, not sorted by posting dates in a direct chronological order. Thus, even in 1C system this process might lead to incorrect bookings. Moreover, in 1C users can’t manually affect the application process of specific invoice to specific payment – under “on contract level” setup it can only be done automatically, thus NAV in this case provides even more flexibility to the user.
However, I would generally not recommend to use automatic application of entries, as there is a huge risk that operations would not be applied to each other in a correct sequence, thus resulting in incorrect accounting operations and reports.
[perfectpullquote align=”full” bordertop=”false” cite=”” link=”” color=”#fa8d29″ class=”” size=””]Summary[/perfectpullquote]- Application of entries in NAV is a critical process for Russian accounting.
- Generally the manual application of transactions in NAV is the same time-consuming process as in 1C when there is “on document level” setup. Do not trust accountants who complain :-).
- We do not recommend automatic application of entries in NAV anyway as there is a risk of incorrect postings.
