Factoring Prospective Receivables? WTH?

In case you’ve missed the Greensill Capital masterpiece debacle. Here are couple of articles with good, clear explanations to help you get caught up.

Greensill didn’t just finance Bluestone’s supply chain

Imaginary invoices are hard to collect

The quick version is Greensill financed receivables (factoring) and payables (reverse factoring). For receivables, they paid the company now at a discount and collected the full amount from the customer later. For payables, they paid on time and collected from the company at a premium later. This isn’t new. My perception, having been involved with factoring a little, is that it tends to be either a well-established practice in certain industries or a bit of a last-ditch lender. But it is short-term financing with collateral. The collateral is the receivable obligation and typical terms are 30-90 days. Definitely short-term.

In Greensill’s case with Bluestone, they appear to be lending against PROSPECTIVE customers and FUTURE invoices. What? I picture a pitch like this: “Look Mr. CFO. We know you don’t sell to Bob’s Bait and Sushi Limited right now, but someday they may decide to do business with your company. How much do you think they would spend? $10 million? Ok, we’ll loan that to you on 90-day terms. Just pay us the discount (interest). If you don’t pay it back in 90 days because not only have you not sold them anything, no one has even called up Bob’s, we’ll roll the loan for another 90 days.”

As Matt Levine put it in Greensill didn’t just finance Bluestone’s supply chain:

Greensill basically gave Bluestone a payday loan for a job Bluestone hadn’t yet applied for.

It appears as though Greensill also managed to package this mess up and securitize it, selling it as receivables loans to Credit Suisse. That part of the story is murky, but it’s hiding in there. Part of the murk is also an apparent conflict of interest at Greensill involving metals magnate Sanjeev Gupta and his collection of companies, called GFG Alliance.

Now Greensill is insolvent and Grant Thornton has been called in to help. Apparently, they are stumbling across these prospective receivables and try to collect them. It’s not going well.

As of now, it’s not even fraud…yet. The securities sold could constitute fraud if Credit Suisse was unaware of the “prospective” part. Bluestone is suing because it believed this was long-term financing, but there’s no mention of how they booked the transactions on their financial statements. And there’s enough murkiness here that I suspect fraud will rear its ugly head eventually. For all this, we learn that somehow a fake receivable isn’t a fake receivable if everybody agrees beforehand they are fake and you just change the name.

The last paragraph of Imaginary invoices are hard to collect was perfect so I’ll quote it in full:

I do not envy Grant Thornton. Their job right now is pretty much going around to companies, presenting them with invoices, and getting laughed out of the room: “That’s not our invoice, we’ve never even heard of Liberty Commodities or Greensill, get outta here.” And then they go back to Greensill with their findings and get laughed out of the room again: “Of course it’s not their invoice, they were just a potential customer, how could you be so naive?” And then Grant Thornton has to tentatively ask, “Well, okay, but then who is going to pay this invoice?” And then there is a long awkward silence.

Don’t Default to Excel

I’m a big fan of Excel. Heck, I’m such a fan I’ve written a couple of books around it. I have a tool built on it. It is unequivocally the glue that holds financial departments, and in some cases organizations, together. Sometimes though, people take that too far. All too often users lean into Excel because it’s familiar. Instead of learning the application sending data to Excel, they simply export to Excel. Why is this bad? Let me count the ways.

  1. Excel isn’t as good as a dedicated tool. I see this where systems have tools dedicated to a task and instead of using those tools users choose Excel. A great example of this is bank reconciliations. ERP systems have dedicated bank rec modules. They are designed with appropriate controls, imports from bank records, and math that always works. Still, a fair number of people choose to skip using bank rec modules and do it via Excel. It’s always messy. It’s easy to get the math wrong. It’s also not something that auditors are a fan of because Excel sheets are more prone to manipulation. I’ve seen at least one person fired for this when flaws in their Excel sheet were exposed.
  2. Excel may add work. This happens when users reflexively export to Excel without understanding the core system. Many times I’ve seen users export data and build a big report from scratch in Excel. This process gets repeated month after month. Later, sometimes years later, they realize that the system actually has the report they needed and they could have avoided all the wasted effort.
  3. Excel can add complexity. Similar to the last item, I see users export data from multiple reports and pull data together with vlookups. In the process, they build a mess because they don’t understand the underlying data. Just because data can be connected a certain way, doesn’t mean it is connected that way. There may other elements required for an appropriate connection. Explaining the mess tends to be hard on the ego of folks who created the mess. It’s exhausting convincing them that their Excel model is wrong. Excel is not always the best choice for connecting data, that’s why databases exist. There’s a second part to this as well. If you’ve ever inherited someone else’s Excel sheet, you understand how difficult it can be to simply understand, not mention untangle, what they’ve done.
  4. Excel can include errors. This one is pretty obvious. We’ve all made an Excel math error, formula error, something, heck multiple somethings. Experienced folks build checks and balances into their sheets and that adds another level of complexity. Sometimes this gets overblown, but it takes a lot of work to protect a sheet against errors.

I have absolutely nothing against Excel. I use it a lot, but I don’t default to it. Excel shouldn’t be a primary tool. It should be a fallback when a primary tool falls short. Take the time and energy to figure out primary systems and use Excel to fill in the gaps.

Why are you still using the GP Stock Status Report?

couple carrying cardboard boxes in living room

It’s a valid question. Why are you still using the GP Stock Status Report? or even the Historical Stock Status Report?

The Stock Status Reports aren’t designed to tie to General Ledger. The Historical Inventory Trial Balance (HITB) is designed to tie to GL.

From Microsoft’s own: How to determine, maintain, and report accurate costing in Inventory, pg 9

In conclusion, we recommend that customers do not use the Inventory Historical Stock Status report to adjust or balance to the general ledger. The report was not designed for that purpose. While FIFO/LIFO perpetual inventories may be very close in balancing, there are issues still pending that would keep this report from balancing to the general ledger.

HITB has been out since GP 10 SP2, way back in 2008, yes 2008. HITB becomes a teenager this year. Despite this, I still see a lot of people still using the Stock Status Report. It’s long past time to move off Stock Status and on to HITB.

Dynamics GP: Slow-Moving Inventory

couple carrying cardboard boxes in living room

I realized the other day that I’ve only posted this code in a reply, never as its own post, so I’m adding this now.

Slow-moving and obsolete inventory is traditionally a measure of inventory destined for markdown and ultimately write-off if not addressed. The nature of what is slow-moving and obsolete varies dramatically. Fresh bread is slow-moving if it hasn’t sold in a couple of days, heavy equipment could be months. Each organization determines what is slow-moving or obsolete.

This code compares inventory items to sales to determine items with quantities on hand that have not sold with the timeframe set in the date area.

SELECT IV00101.* FROM
dbo.IV00101 INNER JOIN
dbo.IV00102 ON dbo.IV00101.ITEMNMBR = dbo.IV00102.ITEMNMBR
WHERE
(dbo.IV00101.ITEMNMBR NOT IN
(SELECT
dbo.SOP30300.ITEMNMBR
FROM dbo.SOP30300
INNER JOIN dbo.SOP30200
ON dbo.SOP30300.SOPNUMBE = dbo.SOP30200.SOPNUMBE
AND dbo.SOP30300.SOPTYPE = dbo.SOP30200.SOPTYPE
WHERE (dbo.SOP30200.DOCDATE BETWEEN
CONVERT(DATETIME, ‘2019-03-01 00:00:00’, 102) AND CONVERT(DATETIME, ‘2021-02-28 00:00:00’, 102))
))
AND (dbo.IV00102.QTYONHND > 0)

Note: I had this in my set of scripts with no notations, that usually means I wrote it, however, I see that I posted a link to a version of this written by Mohammed Doud. The link is now gone so I’m not sure if this is his version or mine and I don’t want to take the credit if it’s his. Either way, it’s useful.

Dynamics GP and SOC Reports

At Fastpath, I occasionally get questions about SOC reports for Dynamics GP. In many cases this results from misplaced or misunderstood auditor questions.

The AICPA’s Service Organization Controls (SOC) framework is a standard for controls that safeguard the confidentiality and privacy of information stored and processed in the cloud. Essentially, SOC reports provide a level of assurance such that auditors don’t need to individually audit every cloud provider for every client. The key phrase there is “in the cloud”.

Since Microsoft doesn’t host GP in the cloud, it sells GP as an on-premise application, Microsoft doesn’t issue any SOC reports for GP. Indeed, it can’t issue SOC reports because it doesn’t host GP in the cloud. With respect to GP, Microsoft is software vendor not a cloud service provider.

If GP is hosted locally by the organization there also wouldn’t be a SOC report required. An auditor would simply test controls locally.

Where this gets interesting is when a company hosts GP somewhere else. This could be running GP in a shared data center, hosting GP in an AWS or Azure virtual machine, or using GP in a SAAS environment from a full service provider. In any of those scenarios one or more SOC reports would be appropriate.

Microsoft for example, offers SOC reports for Azure and the Dynamics products that it hosts (Like Dynamics 365 Finance and Dynamics 365 Business Central)

There are two main categories of service audits based on the SOC framework, namely a SOC 1 and SOC 2.

A SOC 1 audit evaluates the effectiveness of a cloud service provider’s (CSP) internal controls that affect the financial reports of a customer using the provider’s cloud services. SOC 1 reports are appropriate in situations where the service provider has access to GP data or other tools that could affect the financial statements. This would include something like Management Reporter, but might exclude an HR product. Despite the sensitivity of HR data, HR data isn’t used for financial statements.

A SOC 2 audit gauges the effectiveness of a CSP’s system based on the AICPA Trust Service Principles and Criteria. A SOC 2 evaluates the processes and controls of the service provider. A SOC 2 might be used alone in a scenario where a server is simply hosted in a data center and where the data center is responsible for physical security, but doesn’t control the customer’s server. It might also be appropriate for a cloud provider where the data doesn’t affect financial statements, like our HR application described above.

SOC 1 & 2 reports can also be a Type 1 or a Type 2. In a Type 1, the company describes its controls and provides documentation as of a point in time. The auditor’s report is based on reviews of the controls and documentation. A Type 2 report provides a higher level of assurance than a Type 1. With a Type 2 report, the auditor reviews both the design and the operating effectiveness of controls over time. Since a Type 2 SOC takes time, often 6 months or more, many organizations pursue a Type 1 audit until they are able to complete a Type 2.

At the conclusion of a SOC audit, the service auditor renders an opinion in a SOC 1 Type 2 or SOC 2 Type 2 report. The report describes the CSP’s system and assesses the fairness of the CSP’s description of its controls. It also evaluates whether the CSP’s controls are designed appropriately, were in operation on a specified date, and were operating effectively over a specified time period.

Microsoft has a nice review of SOC reports at this link https://docs.microsoft.com/en-us/compliance/regulatory/offering-soc

SOC reports provide a level of assurance for users of a service provider. They also simplify the audit process for users since auditor can evaluate and choose to rely on a SOC report instead of performing their own audit. Choosing a cloud service provider without a SOC report is not generally recommended, but SOC reports only apply to Dynamics GP when it is hosted somewhere.

Personal Note: There’s Less of Me

Since we haven’t seen each other in person lately, and it will probably be a while until we do, I though you might want to know there’s less of me now. I covered this on my personal blog, link below.

https://mpolino.com/weight-loss-success-and-failure/

Underused Software Syndrome

Do you have low level anxiety, a feeling you’re not getting everything you could out of your existing software? Is there a nagging guilt that it’s your fault? Does it seem if only you had more time or training you could really master that piece of software and life would be so much easier?

Welcome to Underused Software Syndrome!

I’ve searched for a term for this phenomenon and not found one so I’ve decided to coin my own. Feel free to set me straight if this anxiety already has a name.

I see this low-level fear a lot. The idea that there is something more, some magic, hiding in a piece of software. Finding this magic would result in a life of unicorns, rainbows, and tropical drinks…or so we believe. Part of the challenge is that occasionally we do stumble onto a feature that solves a significant problem or increases productivity. That reinforces the syndrome. Surely the developers added more features like the one we just found if only we had time to look harder. With Underused Software Syndrome, we think software problems are our fault. While it’s right to want to be more productive and to solve problems, it’s wrong to blame yourself.

Underused Software Syndrome manifests frequently in business software users. Users of applications like ERP systems (accounting), CRM (sales), and even Office apps like Excel are common sufferers. The software is so big and complex that user’s blame themselves for not being more efficient. This seems to be a form of impostor syndrome mixed with a little FOMO, the fear of missing out. The user feels that despite their knowledge of their job and the relevant software, they don’t know enough and they aren’t good enough. Surely everyone else is getting more out of the software.

I’m sure this feeling isn’t limited to business software. Video editing and graphic design software seem more than complex enough to generate Underused Software Syndrome feeling. I just have more experience with business software.

In some cases, there’s a financial element to the feeling of Underused Software Syndrome. The idea that software is expensive, and it’s fiscally responsible to use as many features as possible, can sometimes underly the feelings of anxiety. Much like an underused gym membership, people feel guilty if they aren’t fully utilizing it.

In other examples, anxiety may manifest itself based on unfulfilled expectations. Users believe that a software package should have a particular feature and that feature should behave a certain way. Features often manifest differently than expectations leaving users with a vague feeling they missed something.

Finally, there is the fear of missing out. For example, lots of people use Excel and lots of people use a tiny fraction of Excel’s features. Even if they know a feature is there, they have to remember the feature exists at the time they want to use it. Most people are not experts in a given software and most are not getting more out of it than you are.

People like me make this worse. For a long time, I’ve helped people get the most out of the software they own. But that was part of my job. It’s also something I really enjoy, and yet I feel Underused Software Syndrom symptoms about software I deeply understand.

I differentiate underused software from shelfware. Shelfware is software that is not being used. The organization may still be paying maintenance or fees for software they aren’t using at all. Shelfware is easier to address. Ignore the sunk costs and cancel any maintenance or monthly fees. Alternatively, revisit why the software was purchased in the first place and potentially put it to use.

Underused software is harder. The organization is getting some value from the software, maybe not enough value to match the cost, but value nonetheless. It’s hard to toss out software that is being used.

I have a couple of thoughts on options to address underused software and it’s related syndrome:

  1. Accept that value is being generated by using the software. Even if it’s only used for a small task, it is still helping accomplish the task. Accept that this software does this task and move one. Sometimes you just need to accept something and move on.
  2. Evaluate the value of that task against any ongoing costs. A small task with a big cost is not a good value proposition. In that case, it may make sense to figure out if there are additional uses or if it’s time to switch to something else.
  3. Pick one thing to improve and search for that. You’d be amazed at what’s available for any given piece of software. Maybe there’s a need to automate a process or export data, whatever. Someone else has probably already tried it and written about it. At a minimum, you’ll get an answer that something can’t be done. Even in that worst-case scenario, a quick answer makes it easier to stop obsessing and move on to the next thing.
  4. Make sure the organization has the latest version. Underused software may be neglected enough to be on an old version. Updating can reveal improvements in features and UI that help resolve anxiety.
  5. Get some help. It’s a big world. There are books, classes, training, blogs, videos, you name it, on some of the most obscure software ever made. There are resources to help. Use them.

“But I don’t have enough time” is the common refrain. There is a problem, but not a priority. People find the time for a priority. It’s okay if this isn’t a priority right now. When it becomes a priority you’ll make the time. Until then, don’t stress about it.

Vote for my DynamicsCon Session!

DynamicsCon is a FREE 2-day virtual learning experience for Microsoft Dynamics 365 & Power Platform users and professionals. Previously, Dynamics GP was not included in the mix, but you asked for it and now GP content will be included as well.

But YOU HAVE TO VOTE!

If you want GP content, go and vote for it at https://dynamicscon.com/submissions/. Hurry, you only have a couple of days. Voting closes this Friday the 22nd.

I would love for you to vote for my session, 50 Security Tips for Dynamics GP at this link: https://dynamicscon.com/submissions/?query=polino, but ultimately vote for any of the GP content that appeals to you!

Fastpath Update blog series – Platform

In addition to module updates, the Fastpath team added a number of cross-module improvements to our platform in 2020. Some of these updates added significant power to what users can do, while others improved usability.

Check out the list at:

https://www.gofastpath.com/blog/fastpath-assure-updates-blog-series-assure-platform