12
Dear All,
Working with D365 Business Central, it seems that Cash Management requires a thorough review.
Currently, it is possible to import bank statement transactions using Bank Reconciliation journal, Payment Reconciliation Journal and General Journal. While bank payment files are created in Payment Journal. It causes a lot of confusion from the point of view of the user, makes the process very cumbersome and not straightforward, because bank transactions are being processed from 4 different places in Business Central.
Please review the scenario steps:
Step 1 – Payment run in Payment Journal
A. Entries are created in Payment Journal using "Suggest Vendor Payment" functionality.
OR
B. Entries are created in Payment Journal using not "Suggest Vendor Payment" functionality. The user specifies which definite invoices should be paid, using Apply Entries.
Step 2 – Creation of Payment file from Payment Journal
Payment file is exported from Payment Journal, in order to be uploaded into bank.
Step 3 – Import of Bank Statement Transaction lines
A. If entries from Payment journal (with specific application to document) are not posted from Payment Journal (because we do not know the date, when payments are executed), these lines are deleted from Payment Journal.
! Then importing bank transactions using Payment Reconciliation Journal, requires the user to go through the "Applying" process once more for outgoing payments. This causes additional work and also may lead to mistakes. [repetitive additional step].
! "Transfer difference to account" per each line that has no application (for example, when bank does not give the commission text in the SEPA file or taxes are paid, loans received or paid) does not make sense. [additional unneeded step per each unapplied line]. If the system did not find a match and the user has manually insterted the balancing account, why “Transfer Difference to Account” need to be used?
! Payment Reconciliation journal has a function to "Post Payments" and not perform the reconciliation. This way, the user is forced to use also Bank Reconciliation, in order to mark the bank ledger entries as closed, otherwise he will not be capable of posting the next Payment Reconciliation journal because of statement ending balance mismatch (bank ledger entries not closed) [additional unneeded step]
! Payment Reconciliation journal has a function to "Post Payments and Reconcile". This way, the user should not use Bank Reconciliation, because the bank ledger entries are already marked as closed. Importing Bank Reconciliation would cause duplicate transactions to appear.
! All entries posted from Payment Reconciliation Journal have the same Document No., however it should be one statement no. and several document no., because each transaction is a seperate document, that confirms incoming or outgoing payment.
! Payment Reconciliation Journal does not recognize transactions in foreign currency, despite the fact that SEPA format provides this information, in order to capture the Exchange rate used per transaction.
OR
B. If entries from Payment journal (with specific application to document) are posted from Payment Journal. Then user cannot use Payment Reconciliation journal, in order not to import the duplicates. Instead bank transactions are uploaded using Bank Reconciliation Journal to make the matching.
! There is not control of importing duplicates in Bank Reconciliation Journal.
! All non matched entries need to be transferred to General journal batch, in order to be posted. [additional repetitive step]
The user most probably shall use Map-Text-To-Account functionality, however there is no "Apply Automatically" function to match the incoming payments with Customer Invoices, that would make life easier.
Step 4- Reconcile Bank transactions
A. Additional control "Bank Reconciliation" is used in all cases, in order to identify if any bank transactions are not yet posted. But this functionality has no option for duplicate detection or error correction, when application was posted as wrong.
The process should be re-engineered:
1. There should be one place, where the payment run is done and payment file is exported despite the way how it is done – using system process or manually
2. Same place to be used, in order to import bank statement, whereas existing lines that have a mark “exported” should be updated with the posting and document date; new lines should have ability to use “Map-Text-To-Account” and “Apply Automatically”;
3. The user should not be forced to use Bank Reconciliation on a daily basis to close the bank ledger entries. Bank Reconciliation might be used for control purposes, when the Accountant compares bank statement lines with bank ledger entries.
Working with D365 Business Central, it seems that Cash Management requires a thorough review.
Currently, it is possible to import bank statement transactions using Bank Reconciliation journal, Payment Reconciliation Journal and General Journal. While bank payment files are created in Payment Journal. It causes a lot of confusion from the point of view of the user, makes the process very cumbersome and not straightforward, because bank transactions are being processed from 4 different places in Business Central.
Please review the scenario steps:
Step 1 – Payment run in Payment Journal
A. Entries are created in Payment Journal using "Suggest Vendor Payment" functionality.
OR
B. Entries are created in Payment Journal using not "Suggest Vendor Payment" functionality. The user specifies which definite invoices should be paid, using Apply Entries.
Step 2 – Creation of Payment file from Payment Journal
Payment file is exported from Payment Journal, in order to be uploaded into bank.
Step 3 – Import of Bank Statement Transaction lines
A. If entries from Payment journal (with specific application to document) are not posted from Payment Journal (because we do not know the date, when payments are executed), these lines are deleted from Payment Journal.
! Then importing bank transactions using Payment Reconciliation Journal, requires the user to go through the "Applying" process once more for outgoing payments. This causes additional work and also may lead to mistakes. [repetitive additional step].
! "Transfer difference to account" per each line that has no application (for example, when bank does not give the commission text in the SEPA file or taxes are paid, loans received or paid) does not make sense. [additional unneeded step per each unapplied line]. If the system did not find a match and the user has manually insterted the balancing account, why “Transfer Difference to Account” need to be used?
! Payment Reconciliation journal has a function to "Post Payments" and not perform the reconciliation. This way, the user is forced to use also Bank Reconciliation, in order to mark the bank ledger entries as closed, otherwise he will not be capable of posting the next Payment Reconciliation journal because of statement ending balance mismatch (bank ledger entries not closed) [additional unneeded step]
! Payment Reconciliation journal has a function to "Post Payments and Reconcile". This way, the user should not use Bank Reconciliation, because the bank ledger entries are already marked as closed. Importing Bank Reconciliation would cause duplicate transactions to appear.
! All entries posted from Payment Reconciliation Journal have the same Document No., however it should be one statement no. and several document no., because each transaction is a seperate document, that confirms incoming or outgoing payment.
! Payment Reconciliation Journal does not recognize transactions in foreign currency, despite the fact that SEPA format provides this information, in order to capture the Exchange rate used per transaction.
OR
B. If entries from Payment journal (with specific application to document) are posted from Payment Journal. Then user cannot use Payment Reconciliation journal, in order not to import the duplicates. Instead bank transactions are uploaded using Bank Reconciliation Journal to make the matching.
! There is not control of importing duplicates in Bank Reconciliation Journal.
! All non matched entries need to be transferred to General journal batch, in order to be posted. [additional repetitive step]
The user most probably shall use Map-Text-To-Account functionality, however there is no "Apply Automatically" function to match the incoming payments with Customer Invoices, that would make life easier.
Step 4- Reconcile Bank transactions
A. Additional control "Bank Reconciliation" is used in all cases, in order to identify if any bank transactions are not yet posted. But this functionality has no option for duplicate detection or error correction, when application was posted as wrong.
The process should be re-engineered:
1. There should be one place, where the payment run is done and payment file is exported despite the way how it is done – using system process or manually
2. Same place to be used, in order to import bank statement, whereas existing lines that have a mark “exported” should be updated with the posting and document date; new lines should have ability to use “Map-Text-To-Account” and “Apply Automatically”;
3. The user should not be forced to use Bank Reconciliation on a daily basis to close the bank ledger entries. Bank Reconciliation might be used for control purposes, when the Accountant compares bank statement lines with bank ledger entries.
STATUS DETAILS
Completed
Business Central Team (administrator)
UPDATE: the past few releases we've made improvement to both bank rec and payment rec journals. - including fixes for some of the docs content has also undergone a few revisions and the sections on Overview of Tasks to Manage Accounts Payable - Business Central | Microsoft Docs and Overview of Tasks to Manage Receivables - Business Central | Microsoft Docs should provide you with a good overview of the two areas as well as linking to related content.
Few pain points, like duplicate entries, Posting Only... in Pmt Rec Journal, etc.., will be addressed in a coming release, so keep an eye on the release plans: Dynamics 365 and Microsoft Power Platform release plans | Microsoft Docs
A few ideas mentioned in your feedback would be better suited as separate Ideas (if you feel like promoting these specifically), but I have noted the feedback and will of course consider it for future releases.
Best regards,
Brian Nielsen, Program Manager
Business Central team