Microsoft Dynamics GP February Hotfix 2019 Including Electronic VAT Changes has released!!

The GP February Hotfix is out with VAT Fixed, Canadian Payroll fixes and some other bit. Find out more at:

https://community.dynamics.com/gp/b/dynamicsgp/archive/2019/02/12/microsoft-dynamics-gp-january-hotfix-2019-including-electronic-vat-changes-has-released

For more details on Electronic VAT and how it’s implemented in GP, check out the documentation.

GP Easy Security Fixes: Customer Payments

[In this series, we’re looking at quick fixes to improve GP security.]

Full disclosure, controlling customer payments is not the easiest fix, but it’s really important.

While most people involved in accounting understand the basic risks around payables transactions, there is also a long history of fraud around receivables. In many cases, this involves intercepting payments and then manipulating the accounting records to hide the missing payments. Two common manipulations are lapping and write-off/discount adjustments.

Lapping involves intercepting a payment and then applying future payments, or payments from a different customer, to hide the stolen funds. GP provides extremely flexible options for applying, unapplying, and reapplying payments until receivables transactions are sent to history. Even in history, the RM Transaction Unapply tool present in the Professional Services Tools would allow unapplying historical receivables for reapplication.

There are multiple places in GP to control applying receivables so the easy fix to prevent lapping is to separate the receipt of payment from the entry of payments. A lockbox, including using GP’s lockbox functionality, is a great way to deal with this. If a lockbox isn’t available, a user should receive checks and either make copies for application or log the checks. A different user should be applying the payment. 

With write-off/discount adjustments, a user again intercepts a payment, but they hide that payment by writing off the related invoice. The customer doesn’t receive any indication that their check wasn’t properly applied. Identical in concept, a discount could be applied to eliminate the balance instead of using a write-off. 

Controlling maximum write-offs in GP is one way to reduce the risk of fraud. The maximum write-off amount is per customer and controlled via options in Customer Maintenance so limiting access to Customer Maintenance is crucial.

Receivables Setup can require a password to exceed the maximum write off, but that assumes the user can’t just change it via Customer Maintenance. Also, that password is a shared password stored in plain text in SQL so it’s not especially secure.

Separating receipt of payments from write-offs and discounts is still the best defense against fraud here. Additionally, regular reviews of write-offs and discounts to supplement other controls is important. 

If a user can gain physical access to customer payments there are many opportunities for fraud. These aren’t just theoretical opportunities either. Accounting literature is full of companies who have been hit by receivables fraud.  Don’t let your company be one of them.

You can find all of the fixes in this series at GP Easy Security Fixes.

Don’t Rely on Microsoft Dynamics GP’s Secondary Controls

I’ve got a new piece up at MSDW: Don’t Rely on Microsoft Dynamics GP’s Secondary Controls. You can check out the piece here:

https://msdynamicsworld.com/story/dont-rely-microsoft-dynamics-gps-secondary-controls

Like so many things, the world of software security has changed and secondary passwords stored in plain text in the database then revealed in plain text in the interface, just don’t meet the standard anymore.

GP Easy Security Fixes: Vendor and Customer Maintenance

[In this series, we’re looking at quick fixes to improve GP security. ]

Most people involved at all in accounting understand that if a user has access to manage vendors and payments that it is pretty easy to create false vendor records and generate payments to those false vendors. In other words, it’s the fast lane to fraudville.

Only slightly more complicated are similar schemes involving customers. Payment redirection fraud can be just as dangerous and harder to detect. All this risk leads to some pretty simple advice, don’t allow users with access to manage vendors to also manage payables transactions. The same advice goes for customers.

In GP, vendor and customer access correspond to the Vendor Maintenance and Customer Maintenance windows respectively.

That’s it. The end.

If only it was that simple. It’s also possible to manipulate a vendor address and redirect a legitimate payment to a different address. In GP, as with many other systems, address records are separate from master record records to accommodate multiple addresses. Additionally, electronic payment setup (EFT/ACH) is also tied to specific vendor addresses to allow multiple options. This adds another dimension of security to addresses since we’re not just talking about redirecting a check, but electronic payments as well.

GP’s tasks reflect this connection between master records and addresses. The task Cards_0301* provide access to vendors and vendor addresses, while Cards_0201* provides access to customers and customer addresses.

The biggest issue out of the box is that these tasks belong to a large number of roles and many of those roles also provide access to vendor or customer transactions. Simply separating these tasks into roles that can be used to better manage master record access is an easy fix, but there’s one more catch. 

Often, users need to access the data in vendor and customer cards. The obvious answer is to grant access to corresponding inquiry windows. These are read-only windows intended for users who only don’t need to make changes, but there is one big problem, inquiry windows don’t always include every present on an entry window. For example, the Vendor Inquiry window doesn’t show if a vendor is on hold. Nor does it include the related 1099 address. Vendor Inquiry also doesn’t provide access to accounts to review accounts associated with a vendor, nor is there a way to review email or project settings via the inquiry window. 

These missing fields are often used as an excuse for granting broad access to maintenance windows. That excuse is a trap. If read only access is required for information not available on an inquiry window, find it someplace else in Dynamics GP. For example, the Vendor Navigation list can identify if a vendor is on hold. SmartLists are also a great option for showing data in a read only format. A SmartList is just as fast as an inquiry screen and provides the necessary information without exposing the organization to the unnecessary risk. 

Finally, if there is simply no way to separate customer/vendor master records from transactions, consider using Dynamics GP’s Workflow features as a mitigating control. But mitigating controls are not as good a primary controls so companies should make a determined effort to separate these functions before turning to mitigation here.

You can find all of the fixes in this series at GP Easy Security Fixes.

GP Easy Security Fixes: Bank Transactions and Reconciliation

[In this series, we’re looking at quick fixes to improve GP security. ]

When we look at controls, every company, even the smallest companies, even organizations that don’t really know what controls are, uses the most ubiquitous of controls, bank reconciliation. It’s one of the few regular, independent checks of what goes on in a company. I’ve seen senior accountants get fired for poor bank reconciliation management and I’ve seen awful bank reconciliations as a symptom of deeper problems in a company that ultimately failed spectacularly.

As a result, it makes sense to ensure that users who perform bank reconciliations are independent from transactions. A review of bank reconciliations isn’t enough. It’s easy to hide transactions from a review. 

Bank reconciliation really needs to be performed by someone with an independent attitude not tied to transactions. Ideally, it should performed daily to provide the greatest benefit, but even the traditional monthly reconciliation, but provides and effective control if done right. Finding the right position to reconcile bank accounts can be tough for organizations. Often the person best positioned to perform the reconciliation is also the person in the best position to manipulate the results. 

In Dynamics GP, the window is Reconcile Bank Statements and it is the only item included in the task TRX_FIN_008*. By default this does NOT include posting, but would allow a user to make adjusting entries, just not post them. Adjusting entries in GP bank rec are designed for things like bank fees or interest, items that are typically first reported on the bank statement, but they can be used for almost anything. Bank rec users should not have access to other types of bank transactions. Additionally, a policy of forcing adjustments to be made outside of bank reconciliation provides another measure of safety.

Reconcile Bank Statement Task

The real keys are to first ensure that this task is not combined into other roles that allow transactions against bank accounts and second to ensure that when a user is a assigned a role with bank rec included, they are not also assigned transactional roles. 

Bank reconciliation is a core control. Ideally, it’s performed daily, to be as timely as possible, and by someone not involved in transactions for some level of independence.

You can find all of the fixes in this series at GP Easy Security Fixes.