The Latest Iteration of the Virtual Close in Accounting

By Brian Busch in API Industry Trends, procure-to-pay Posted Oct 5, 2020

Do you ever feel haunted by the ghosts of problems-past?

Forgive the off-season reference to Scrooge...and let me explain.

If you search for “virtual close” on, you’ll see posts going all the way back to 1998. So, why then are accounting software vendors like Blackline and consultants like Deloitte still marketing and providing guidance around something that surely most companies should have solved over the past two decades?

virtual close

First, what exactly is a virtual close? According to this post in AccountingTools from 2018, it’s just a way to produce consolidated financial statements (and information for management) at any time, on demand. The same post goes on to say:

"This approach requires not only enterprise resource planning (ERP) systems, but also a great deal of effort to ensure that the underlying information is correct. The required investment is so large that you rarely see a virtual close in smaller companies."

But what about medium and larger companies? Blackline’s website points out some of the challenges they face: “A reliance on spreadsheets, tribal knowledge, and in-person communication is not sustainable [due to Covid-19]... accounting teams must quickly adapt to closing the books with a distributed workforce.”

Distributed workforce = a more difficult virtual close?

We have Slack and Zoom to communicate, email and Box to manage all those spreadsheets, and Docusign to electronically sign contracts. Sure, sometimes in-person activities like physically signing checks are a necessity, but is it really the “distributed workforce” that makes a virtual close difficult today?

A 2011 post from titled, “What Ever Happened to The Virtual Close?” notes that:

"Cisco is a widely acknowledged pioneer of the virtual close, having been heralded a decade ago for its ability to close the books with the click of a mouse, churning out consolidated financial statements and balance sheets in less than a day. 

Cisco now uses collaboration technology that allows finance to monitor the close and virtually connect the various teams involved in the effort globally... [and] Finance-team members also communicate on key issues via online discussion forums shared with all members of the process."

Remember, this is from 2011. Almost a decade ago (which is scary to say). I suspect the author gets closer to the underlying cause when he quotes the global controller of Mirion Technologies, a maker of radiation monitoring equipment:

"We were formed from several small companies with multiple products and markets and a collection of outdated local ERP systems. The conventional wisdom is to put all the companies on the same ERP system, which would have cost us millions and distracted finance for three to five years. While there are great tools for integrating the consolidations, budgeting, and forecasting, we don’t have the IT resources to be chasing them.”

Consolidating data from multiple ERPs is an integration problem

They say when you’re a hammer, every problem looks like a nail. For us at Cloud Elements, it’s hard not to see these types of challenges in the procure-to-pay space as integration challenges.

Multiple ERP systems that silo critical data (not to mention a host of new software applications for e-commerce ordering and fulfillment, online order tax calculations, mass payments to vendors, etc…) and a premium on financial controls in the uncertainty following a major economic downturn make clear that the CFO can’t do her job without consolidated, accurate data.

A challenge we often see among our direct customers (like Tipalti) or our customers’ customers (like the multinationals running SAP and using SAP’s Cloud Platform Integration) is that sitting behind various applications’ APIs are data, but to aggregate and consolidate accurate, real time information across a multitude of applications requires data operations

When building ERP integrations, a One-to-Many approach makes all the difference

Said another way, the CIO’s office typically thinks about integrations like the graphic on the left (below): move data from application A, map and transform the data, add/update the data in system B, and vice versa. Legacy iPaaS vendors might claim ‘one-to-many’ integration patterns, but their products are still architected for a point-to-point motion (again, the left side of the graphic). Complex integrations built using the left-side paradigm often take months or years and consume valuable IT resources.

However, moving from weeks to days (or even hours) for a successful virtual close requires integration to look like the right side of the graphic: while tribal knowledge and spreadsheets live at the system/application level, an on-demand virtual close is built on reusable data operations (i.e. process-based APIs) and even standardized data models (i.e. canonical data objects).

When combined, the virtual close process begins to look like an application itself, sitting on top of the underlying data sources with the tribal knowledge and financial controls built into the automation logic. Increasingly, core ERP systems like NetSuite and SAP can automate the virtual close, but only if all the supporting applications are integrated with the ERP.

virtual close integration

Unlocking these data operations with data virtualization is the key difference between a traditional iPaaS that promises but doesn't enable a one-to-many pattern and a true API integration platform. 

Learn more about how data virtualization can enable a smooth virtual close and streamline the procure-to-pay process in our latest eBook. 

Get the eBook