Shifting to high gear: The patch management race in new revenue accounting systems

Start adding items to your reading lists:
or
Save this item to:
This item has been saved to your reading list.

The adoption deadline for ASC 606, the Financial Accounting Standards Board’s new revenue recognition standard, has passed for many public companies, and nonpublic entities are well on their way to meeting their 2019 effective dates. But we hear frequently from clients that the enhancement of their revenue management systems (RMSs) remains challenging. New RMS software versions are being released far more frequently than with other large-scale IT implementations. And managing those patches while maintaining compliance requires an unusually robust strategy that contains both business and IT considerations.

Patch management complications

To correct RMS software defects and incorporate new functionality, solution vendors recommend installing the most current patch at the time that it’s provided. The benefits of prompt upgrade are substantial: companies can take advantage of the latest functionality, receive updated vendor support, and facilitate implementation of future patches.

Immediate application of the newest patch is impractical because companies simply cannot keep up with the churn of new patches, which may be released quarterly, monthly, or even more frequently. Moreover, by the time companies complete the testing and implementation of one patch, a new patch has typically been pushed out, causing many organizations to fall one or more patch levels behind. Also, the installation of a new patch may unintentionally decrease functionality in an area that previously worked fine.

RMS patch challenges

High patch frequency

Patches are released quarterly or more frequently, which may not allow sufficient time for testing, patch deployment, testing execution, and patch validation prior to implementation in production.

Impact:

  • Defects detected on a company’s patch level may already have been resolved by a future patch release. The vendor cannot fix the issue on a company’s current patch
  • Movement to the new patch level requires regression testing to confirm new and existing functionality
  • Executing patch testing and implementation requires significant business and IT involvement
  • Code freezes can cause organizations to fall even farther behind

View more

Instability

The solution’s maturity level is low, and patch releases involve fixes that may affect existing functionality.

Impact:

  • Patch releases may go to market with improvements as well as new defects. In other words, fix one thing but break another
  • Business users should conduct and confirm core scenario testing and reporting prior to patch implementation

View more

Extensive testing

The scope of testing to confirm both existing and new functionality can be extensive for each patch release.

Impact:

  • Testing and confirmation can raise resource management challenges due to the heavy demands on both business and IT
  • Providing coverage for the majority of scenarios and functionality is complex. For companies with customized core RMS solutions, determining the right scope may become even more complicated

View more

Business operation impacts

RMS regression testing requires business involvement to confirm accounting accuracy. Testing should be part of the ongoing business process, and business users must be trained to use new functionality.

Impact:

  • The timing for testing and implementing a patch could affect the timing of financial-close and financial-reporting activities
  • Patch implementation should be aligned with patch applications for other IT solutions
  • Resources must be allocated to train users on an upgrade’s nuances
  • Updating desktop manuals and related process and control documentation is also important prior to upgrade

View more

Components of a robust patch management strategy

revrec patch management strategy

To help your organization keep up in the RMS patch race, use a four-part RMS strategy:

  • Review release notes and identify solution and business impacts. Understand testing required based on patch details
  • Confirm patch across multiple instances
  • Integrate patches as appropriate until the second round of systems integration testing.
  • Align to broader IT patch management schedule—with consideration of the business cycle

Contact us

Peter Schraeder

Peter Schraeder

Partner, Digital Risk Solutions, PwC US

Shane Foley

Shane Foley

Principal, Digital Risk Solutions Leader, PwC US

Stephen Sullivan

Stephen Sullivan

Principal, Digital Risk Solutions, PwC US

Follow us