kvitta NAV to BC
Migrating from Dynamics NAV ·7 min read

Moving NAV to Business Central? Do not pay twice for the payment matching hack.

Somewhere in your NAV there is a customisation from 2014 that pulls the payout file apart and applies customer entries. One person understands it. It is not in the migration scope, or it is in the scope at a number that made everyone quiet. There is a third option.

Works on NAV today, works on BC after cutover, unchanged either side.

The uncomfortable part of the migration nobody scoped properly

Your customisation does not come with you
C/AL objects become extensions, and a rewrite is a rewrite. Whatever cleverness applied your Adyen payouts gets specified, quoted and rebuilt from a memory of how it worked.
Rebuilding it buys you the same ceiling
If it cleared sixty percent in NAV, a faithful rebuild clears sixty percent in BC. You will have spent the budget to arrive exactly where you were, with the same spreadsheet beside it.
And then it is yours to maintain, twice a year
Every release wave, someone retests it. Every new payment method, someone opens a ticket. That cost never appears in the migration business case.
The cleaner answer is to stop treating payment matching as an ERP customisation at all. Open items come out, a journal goes back in, and Business Central stays standard.

Four steps that take it off the critical path

You can do all of this before cutover, on NAV, without touching the migration plan.

1

Run it beside NAV now, from an open items export

Kvitta only needs your open customer entries and the payout files. On NAV that is an export, which means you can start this week without a single change to the system you are about to retire.

2

Let the rules capture what the customisation knew

This is the quiet win. Every reference trick and fee mapping buried in that code gets written out as a sentence you can read, because it was derived from your actual files rather than from anybody's memory. Documentation you did not have to write.

Instead of a codeunit: strip the leading SO, drop the suffix after the dash, then match on invoice number.
3

Cut over without AR going dark

On go-live day the process does not change: same files, same rules, same journal, pasted into the BC batch instead of the NAV one. The riskiest week of the project is the one week nothing changed about reconciliation.

4

Delete the line item from the estimate

No extension to build: on a connected plan Kvitta installs one small app, the same for every customer, published and kept current by us. Adding a payment provider changes a rule in Kvitta rather than code inside your Business Central, so there is nothing to re-quote. Your partner gets to spend those hours on things only they can do.

Request early access
Same tool, both sides

Because it never lived inside the ERP, it does not care which ERP you are on

NAV today, Business Central next quarter, and the same rules, the same journal format and the same daily routine throughout.

Before cutover
Open items exported from NAV
After cutover
Open items read from Business Central

Migration questions

Does Kvitta work with NAV as well as Business Central?

Yes. It needs open customer entries and the payout files, which every NAV version can export. Business Central adds a direct connection, but nothing about the daily routine depends on it.

Should we do this before or after the migration?

Before, if you can. Then reconciliation is a known quantity during the noisiest weeks, and it is one less thing being tested for the first time on go-live Monday.

Our partner needs to sign off on anything touching finance.

Reasonable, and easy here: none of the matching lives inside your ERP, and nothing posts automatically. Your team pastes a journal into a batch and posts it, so the control model is the one they already approved.

We have historic unapplied entries going back years.

Bring them. Old entries are usually a handful of patterns repeated, which is exactly what rules are for, and clearing them before cutover means less to migrate.