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:

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:

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.