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.

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.