Dynamics NAV 2017 – US CRONUS Account Data Needs Help

CRONUS is the sample data company for Dynamics NAV. Several months ago, when I installed the first version and started looking at the new features, I noticed something interesting: the system-generated financial statements were out of balance! Ok, let me back up a second.

Until 2017 version, there wasn’t a utility in NAV to generate a set of financial statements. Even simple statements required more than pushing a button…not a lot more, but more. So I was excited to see that NAV finally had a feature like a lot of other mid-range software. In 2017, there was a function that created rudimentary financial statements: Balance Sheet, Statement of Income, and a Cash Flow Statement. But…and it’s a big but…the financial statements were out of balance.

By the time I realized this, I had already dinked with the Chart of Accounts, so I thought I’d done something and just left it. After all, financials are financials. Nope. They were out of balance.

I realized that the way the system was generating the statements was based on the classifications of the accounts on the Chart of Accounts (COA). That was when I noticed that the classifications on the COA were wonky in the sample data. Depreciation classified as Sales, or was it Sales classified as Depreciation.

Anyway, once you fix the wonkyness in the COA, the financial statement generator is pretty cool. It at least gives you the “vertical” dimension of some standard financials.

Be sure to fix your sample data if you’re going to take a look at this feature.

New Phishing Reports

PBusinesswoman getting crazy in front of her laptophishing is becoming more common…and apparently more popular among hackers. Here’s the latest report from the trenches.

IT World Article

So here’s a question: Did you click the link above? Did you check it to make sure it went to ITworld.com or something similar rather than a domain like Youve.BeenPhished.io?

Here’s a general recommendation: if you get an email from your bank, brother, Google, Microsoft, your mother-in-law, etc., make sure you know where it’s taking you before you click it.

Otherwise, you may have been had.

Phishing – This is what it looks like

The screen capture is of a phishing email I received yesterday. It looks perfectly legit, until you read it closely.

First, it is addressed to “Dear Member” Netflix knows my name. After all, they charge my credit card every month. This is the first tipoff.

Screen capture of Netflix Phishing emailSecond, the text of the first paragraph is, “We recently failed to validate your information, we hold on record for your account, we need to ask to complete a brief validation process in order to verify details.” Notice the awkward grammar and sentence structure. It doesn’t sound like someone from customer service at a big US company like Netflix. Of course, I get legitimate emails that sound like this. Most of them are from technical support, though. In the interest of not helping the scheme, I won’t correct the sentence, but you can do it if you wish.

Third–and only some email clients will allow it–if you mouse over but do not click the link, you may be able to see the text of the link as a pop-up window (tooltip) in your email client. The address is not at Netflix, but part of it is businesscen… 

This is a classic phishing scheme. An email that–on the surface–looks genuine. It has the right colors and logo. Look beneath the surface to see the details.

One other thing: even fairly sophisticated people fall for this type of scheme. The emails “hacked” from John Podesta were compromised with a phishing attack. According to one article, when Podesta emailed his IT specialist, he was told the email was “legitimate.” The IT specialist now claims it was a typo. It should have been “illegitimate.” Close but no banana…and no election victory either.

ALERT: Filing Deadlines for Employer Copies of 1099 and W-2 Moved to 1/31

For years, the deadline has been 2/28 to file W-2s. In a seminar last week on tax changes, the presenter made a point that this had been changed to 1/31. IRS made the change to combat the rash of identity theft (IRS will have W-2 and 1099 information to match to).

Here areTax accounting 1040 US Tax Form, with calculator, pen and glasses the SSA and IRS links:




Also note that the penalties for non-filing of information returns (in particular intentional disregard) have increased substantially:


Selecting ERP Software – The #1 Thing to Prevent ERP Failure – Best Practices

If you read more than one study about the reasons for ERP failure, you will know that the #1 reason ERP systems fail is lack of management support for the ERP project. That’s the reason, but it’s not the root cause. The root cause started earlier, even before the first product was identified, the first demo done, and the first proposal requested.

ERP Failure Starts…with budget setting

ERP failure starts in the very beginning of the project. It starts with budget setting. This also applies (perhaps even more) to those companies that “don’t have a budget.” Or those where the budget is, “we’ll spend as much as we have to.”

ERP Failure - Enterprise Resource Planning word cloud with magnifying glass business conceptHumor me while I develop an example. Suppose that your company is about to hire a President. In your company, this position has broad responsibility. The President is responsible for financial management, overseeing purchasing, keeping track of inventory, providing basic data on the sales force, and a list of other duties. You’re setting the salary for the person who will control and manage most of the key items in your business.

After a brief meeting, the CEO says the following, “I think if we look carefully enough, we can find an excellent candidate that will work for $25,000 per year.”

Doomed before the search starts

To put it mildly, this company’s search is doomed before it starts. Every candidate will have less than the required skills. Many good candidates won’t even apply for the position. In the end, either the salary will go up, or a less-than-desirable candidate will be selected.

Of course, you might find a retired business person who just wanted to get back in the game. But are you willing to bet your business on that?

Almost enough is worst of all

Few companies would make this error. After all, my example is so extreme it’s silly… But I’ve seen a lot of companies set a salary at $75,000 when the market required a salary of $100,000. It’s this “almost enough” salary that attracts some talented employees, just not the full slate of skills and experience the company is going to need.

Effect on management…

I mentioned that lack of management support is the #1 reason for Failure. How does that fit?

Every time I see a budget or salary that’s too low, management has set it to be comfortable. If it works out…great! If it doesn’t…well, we can recover without too much trouble.


Management doesn’t have serious skin (money) in the game from the beginning. Play the dirge; it’s going to be ugly!

Where does ERP software come in…

The same thing happens in ERP. Too low a budget restricts both the choices and management’s commitment to the project. My budget formula is just a way to get in the ballpark. The rest of the project will make it clear what the real investment should be…

…next time, how to get started.

Selecting ERP Software – Best Practices – When the budget is too low

So you read my posts on budgeting…and you came away thinking, “He’s too high! We can do it for less!” And you just might be able to do it for less. But before you try, let me relate a true story…this happened to one of my clients about 5 or so years ago. They aren’t the only story I could tell…

A Budget Too Low

The easiest way to explain this is to tell you about my client…I’ll call them E-Corp (hey, if you watch the TV series Dr. Robot, you might know them…not really)

E-Corp set a budget of $150,000 for their software. They needed a lot of software. 40 or so users. Warehouse management. EDI. …and they had a huge need for customization…

You see, the software they had was developed in-house, and they knew they wouldn’t find anything that did exactly the same thing…and the programmer retired…and then the Controller who knew what the software did announced his retirement…

I told E-Corp that $150,000 was too low….but they insisted on that budget…even though I encouraged them to double or triple it...

The last time I talked to E-Corp, they had spent over $400,000..and still weren’t through!

What Happened?

E-Corp started with a list of potential software vendors. They sent them a rough RFP and asked for proposals. Several vendors whose products I knew didn’t respond. The client asked me, “Why?” I said, “Your budget is too low; I wouldn’t have responded either. You aren’t acting serious about this.” 

But because they got a response from a SAP dealer (BusinessOne), they thought they’d go forward. They did demos and discovery. They specified customizations. They drank the Kool-aid, as they say. And then came the proposal. $288,000. The client called me to check the proposal. “Can you help us get it down?” I reviewed it.

“This proposal is too low,” I said. “The fees are all estimates. You’ll never finish the project for this. The fee to product ratio is 50%, and you have data conversion AND extensive customizations.”

“What does the budget need to be?”


They told themselves (and me), “We have the technical ability to get this done for this price.” Only one of us believed them. It wasn’t me.

I told ’em so

The last time I talked to them, they had implemented the software for 2 of 5 business units (the easy ones), and they had spent $400,000 and were two years over schedule.

I can only tell you the truth. I can’t make you believe it.

Selecting ERP Software – Best Practices – Setting the budget

In the last post, I gave you some rules of thumb about software cost. In this post, let’s see if we can come up with a budget for a software implementation.

What you need to know (or estimate)

Before you calculate a budget, you’ll need to answer a few key questions:

  • How many users will you have? I suggest that you count or estimate two different user counts (which might be the same). First, the concurrent user count. That is, how many people will need access to the system at one time. The easy way to estimate this is to count the people that will use the system all day, every day. Then list the people who will use the system only some of the time. You’ll have to decide how many of the “some time” users will be using the system at any one time. One helpful question in the past has been, “Suppose some of our users can’t get on the system (because we are out of users). What is the business effect? The second user count will be named users. A named user is someone who needs a login in the system. The named user count will always be at least equal to the concurrent user count, usually more.
  • Will you convert data? If so, what kind and how much? We divide data into master file data, beginning balances, open documents, and history. Master files are things like customers, vendors, and inventory items. Beginning balances are open payables, open receivables, general ledger balances, and item cost and quantity. Open documents are things like sales orders that have not been shipped and invoiced, or purchase orders not received. History is…well…history. Things like past purchase history (what the customer bought last month or last year), what items were ordered from vendors. Our recommendation is that you keep the old system up and running for a year or two and access history from there.
  • Is the data to be converted both clean and easy to get? If your data is in Microsoft SQL Server, and you constantly clean up customers and vendors, the answer is “Yes.” If you’re using an old system that you’ve had for 20 years, have lots of history, and will need help to extract the data, the answer is “No.”
  • Do you need anything outside the scope of the pricing discussed in the last post? This would be features like manufacturing, service, point of sale, etc.

Looking  for a budget not a price

Before getting into the calculations, let me emphasize that we’re looking for a budget, not a price! Just because we set the budget for the wedding dress at $5,000 does not mean that we have to spend $5,000. We might spend only $1,000. But here’s the key point: I use a budget to eliminate products in the very first step of a selection process. If the vendor can’t tell me that they can deliver a solution within budget, they’re history.

This means that it’s important that the budget be reasonable. And that’s what this calculation will give you. Next post we’ll discuss what happens when the budget isn’t reasonable.

Setting a rough budget

This method is based on two observations about software projects. First, the more users there are, the more implementation is needed. Second, the more users, the more complexity that tends to be introduced into the implementation. This means that in most cases, the more the cost of the on-premises software, the more complex the implementation, data conversion, and customizations will be. And that assumption is what this formula is based on.

This isn’t a quote, and I can’t guarantee that you can implement a system for this amount, but here’s a reasonable budget formula:

  • If you need anything outside the scope of the features in the last post, use the amount $3,500 per user for on-premise software or $225 per month per user for cloud software. Otherwise, use $2,500 for on-premise software and $150 per month per user for cloud software.
  • Multiply the on-premise software number by the number of concurrent users. So if you have 10 concurrent users, you would either calculate $35,000 or $25,000 depending on the features you need. This number is the base number for calculating data conversion, implementation and customization.
  • To determine your data conversion budget, take this figure times 50% if you convert master file and beginning balance data only. Multiply by 75% if you convert open documents. Multiply by 150% if you plan to convert history.
  • To determine your implementation budget, take this figure times 75% if you think you’ll need very little help, 125% if you think you’ll need some hand holding, and 150% if you plan to redesign processes for the new software.
  • To determine your customization budget, multiple this figure by 25% if you just need a couple of reports designed. Multiply by 75% if you think you’ll need to change the way the software works in minor ways. Multiply by at least 100% if you expect to need extensive customization.

If we plan to convert master files and beginning balances, we need some hand holding, and we don’t plan to customize anything other than a couple of reports, we can come up with a budget. So, here’s how the base calculation would work for 10 users of the basic distribution software we discussed in the last post:

One of these:

  • Software budget (on premises): $25,000 ($2500 x 10 users) OR
  • Software budget (Cloud): $1,500 per month


  • Data Conversion: $12,500 ($25,000 x 50%)
  • Implementation: $31,250 ($25,000 x 125%)
  • Customization: $6,250 ($25,000 x 25%)


On-premise: $75,000

Cloud: $50,000 plus $1,500 per month.


Selecting ERP Software – Best Practices – Setting the budget

The first thing many companies do is decide on the budget for a software project. At a high level, I mean; round figures like $5,000, $50,000 or $500,000. That’s a good place to start. But how do you set a budget? Should you go high, low, or reasonable?

Software budgets based on industry surveys

Before we even talk numbers, we need to set the scope. That is, we need to know what we’re talking about in terms of software. Let’s pick something fairly common: distribution or wholesale software. That would include accounting (general ledger, accounts payable, and accounts receivable) as well as operations (inventory, order entry, and purchase orders). For basic, mid-range software you can generally expect to invest between $2,000 and $3,000 per user for software. I’m not talking about the low-end stuff that leaves out a lot of features like pricing, serial numbers, or multiple warehouses. I’m talking about the baseline features that almost every reasonable contender in the mid-market has.

So let’s pick the middle of this range as the price: $2,500 per user. But that’s for software purchase (buying the software). And there will also likely be an annual fee to the software provider for upgrades and maintenance. But what about software in the cloud?

Cloud software pricing

Cloud software pricing is all over the place. Most mid-market solutions run in the range from $125 to $200 per user per month. That includes the infrastructure (Windows, SQL Server, setup, security, etc.) as well as the software license. It can be more; it can be less. This is a decent range. And it usually includes the software maintenance; sometimes it includes upgrades.

What else should be included?

The numbers above include only software (or in the case of the cloud, software plus what you need to run it). There are three other items you’ll want to consider in your budget:

  • Data conversion. This is the cost of moving data from your current system to the new system. For some things like inventory items and customers, it can be pretty simple. For other things  like order history, it can be very difficult. Getting the data into the new software and getting it out of the old software are often straightforward. Cleaning up the data from the old system is where much of the effort lies.
  • Implementation and Training. Implementation is picking the right options and setting up the right processes to make the software work in your business. It also includes the technical setup of the software. Training is for the people who will be using the system.
  • Customization. Depending on the software and how your business runs, you may need customization. This could be as simple as creating a couple of reports. It could be as complex as developing major features for your system.

Industry surveys have shown that these three components generally run from 1 to 4 times the purchase price of the software. Data conversion and customization tend to increase the cost.

Can you do it for less?

Yes, it can be done for less. We have developed a system that can substantially reduce the investment in implementation. However, for most mid-market systems, companies will at least need an employee with recent experience in implementing ERP software.

In the next post, we’ll discuss the importance of setting a reasonable budget.


Selecting ERP Software – Two Critical Keys to Selecting the Right Software

(I generally don’t like RFPs for software because they never seem to produce responses that can be evaluated apples to apples, but I talk about RFPs in this post because people are familiar with them. What I recommend is a “Process and Requirements Document.” We’ll get to that in a later post.)

When I see a typical RFP for ERP software, it usually begins with something like, “ability to define chart of accounts,” “GAAP-compliant financial statements,” etc. Don’t get me wrong, these are important criteria. The problem is that most software packages from the bottom to the top of the market meet these requirements. An RFP needs to pay primary attention to two critical key areas:  feature coverage and unusual requirements.

The Concept: Common software features are not selection criteria.

The easiest software choice is for a company that needs basic features that all ERP software has. I’ve seen companies do elaborate RFPs for general ledger and accounts payable systems. They needed to print financial statements, documents required for accounting, track accounts payable and print checks. Every system I’ve seen from QuickBooks to SAP has these features. It doesn’t matter which system the company chooses, any one will do.

Of course, no company (particularly yours) has needs this simple. But many RFPs include mostly these types of requirements. These requirements are not going to help make a decision on the right ERP system for your company. If you feel that you need to state these requirements, put them in an appendix as a checklist. Then refer to them in the selection document. So what should you focus on in the body of the RFP?

Feature Coverage: The ticket to get in the door

The first thing you need to cover with software vendors–right up front–is the general list of features or functions that you need in the software. In the old days, we might have called these “modules,” but I mean something a little different. So let’s assume that you make toothpaste (process manufacturing). You’ll need at least basic accounting (G/L, A/P, A/R, maybe P/R). You’ll need inventory, purchasing, and sales orders. These things you’ll find in most products (see section above). I would generally summarize these to “basic accounting, inventory management, sales and purchasing.” You’re also going to need some other features, I suspect. It’s these other features that you should focus on in the feature coverage section. Manufacturing recipes (BOMs), shop floor control (if needed), production reporting, work in process, MRP, scheduling, etc.

These features form the “first cut” in selecting software. If you need a feature and the ERP software you’re evaluating doesn’t have it, mark it off the list without further ado. Don’t spend time watching demos of software that doesn’t have the features you need. By the time you get to the demo stage, watching demos will get tiring. More about that later.

So let’s say that by applying your feature coverage needs, you get to a dozen packages that you think might meet your needs. What now?

Unusual Requirements (that aren’t necessarily unusual to you)

Once you weed out the packages that don’t have the feature coverage you need, you should focus on requirements that not all software packages have or that you suspect not all packages have. These generally have to do with the way you operate your business, but they can be accounting requirements. Let’s take accounting requirements first.

Example: Unusual accounting requirements.

Suppose that you have four companies. Two are in foreign companies and keep their books in Euros and Rand’s (ZAR). The other two companies are in the US and keep their books in USD. You need a monthly consolidation of these four entities. To make things a little bit more interesting, you only own 75% of two of these companies (the ZAR currency and one US company). One of the companies has commodities as assets that need to be revalued daily and entries booked in a particular way, and these entries have to be processed in a very unique way for the consolidation. That’s an unusual accounting requirement, and should be documented right up front. In effect, you’re saying to the vendor, “If you don’t have this feature, we can’t use your software.”

Example: Unusual operating requirements.

A second type of unusual requirement relates to the way your company operates. Suppose you have a small manufacturing company. Eighty percent of your revenue comes from products you manufacture and sell through distributors (manufacture to stock). For this business, you make the same products over and over. Twenty percent of your revenue comes from specialty manufacturing orders that come with engineering designs. You create the tooling for these orders, and generally manufacture these only once (manufacture to order or job shop operations). You need to keep up with the costs on a product-by-product or job-by-job basis. Right now you do that with a “job envelope,” but you want to automate this.

So is this really unusual? No, not really. It’s a typical job shop. What makes this unusual is that you also do repetitive manufacture-to-order work. And what makes this important in an RFP is that many ERP systems that have repetitive manufacturing will also say they can do job shop or manufacture to order. Can they? Yes, they can. But you may have to jump through hoops to get the information you need into or out of the system.

Using  these Requirements

Once you have these, here’s how you use them. Feature coverage is your screening criteria. You don’t consider a product that doesn’t have feature coverage. We’ll talk about how to do this screening in a later post.

Unusual requirements become part of your initial requirements list to vendors and are your demo criteria. First, you’ll send an email (or letter) to the software vendor with your requirements. You’ll ask, “Does your software do this?” They’ll respond, and you’ll filter the products by looking at the responses. When you get to the point of demonstrating products, you’ll prepare a demo script. Basically, it says, “Here is the setup you’ll need. Demonstrate how this, this, and this work in your product.” The “this’es” in your email will be unusual requirements. When you see the demos, you’ll be able to compare product to product.

So now you know all my secrets…almost.