WEBVTT

00:00:00.000 --> 00:00:03.390
Since May of 2021, an advisory engagement team had

00:00:03.390 --> 00:00:06.210
been providing managed technology services to a healthcare

00:00:06.210 --> 00:00:09.840
company. The services primarily consisted of managing the

00:00:09.870 --> 00:00:12.840
entity’s enterprise resource planning system, which was

00:00:12.840 --> 00:00:15.270
permissible at the time as the entity was not an audit

00:00:15.270 --> 00:00:17.370
client or an affiliate of an audit client.

00:00:18.030 --> 00:00:22.380
In April of 2023, our audit client, a private equity firm,

00:00:22.680 --> 00:00:24.810
announced it was acquiring a majority stake in the

00:00:24.810 --> 00:00:28.230
healthcare company. As a result, the healthcare company

00:00:28.230 --> 00:00:30.840
would become an affiliate of our audit client upon closing

00:00:30.840 --> 00:00:34.230
of the acquisition. At the time of the announcement, my team

00:00:34.230 --> 00:00:37.290
created a new entity in Sentinel and added it to our audit

00:00:37.290 --> 00:00:39.000
client’s Sentinel family tree.

00:00:39.510 --> 00:00:42.210
The acquisition closed in June of 2023

00:00:42.720 --> 00:00:45.510
During our quarterly independence procedures, we discovered

00:00:45.510 --> 00:00:47.910
that there was a duplicate of the healthcare company within

00:00:47.910 --> 00:00:51.780
Sentinel and after performing a service history review, our

00:00:51.780 --> 00:00:54.840
team identified the ongoing managed technology services for

00:00:54.840 --> 00:00:57.690
the healthcare company that was no longer permissible now

00:00:57.690 --> 00:00:59.820
that they were an SEC restricted entity.

00:01:00.720 --> 00:01:03.870
Initially, my team used the Sentinel Entity Management Tool,

00:01:04.110 --> 00:01:06.510
to add the healthcare company to our client’s Sentinel

00:01:06.510 --> 00:01:09.570
family tree. However, the team overlooked the potential

00:01:09.570 --> 00:01:12.570
matches provided by the tool, which would have alerted us to

00:01:12.570 --> 00:01:15.900
the existence of the entity already in the system. Instead

00:01:15.900 --> 00:01:18.420
of linking the existing entity into our audit client’s

00:01:18.450 --> 00:01:21.780
Sentinel family tree (and running a service history report

00:01:21.870 --> 00:01:24.720
which would have identified the managed services), my team

00:01:24.720 --> 00:01:27.210
inadvertently created a new entity, allowing the

00:01:27.210 --> 00:01:29.010
impermissible services to continue.

00:01:29.550 --> 00:01:32.880
Once my team identified the issue, KPMG immediately

00:01:32.880 --> 00:01:35.850
terminated the impermissible services. However, this

00:01:35.850 --> 00:01:38.310
oversight resulted in a prohibited management function

00:01:38.310 --> 00:01:40.890
violation that needed to be communicated to our client’s

00:01:40.920 --> 00:01:43.980
Audit Committee and I was assessed a Category 2 sanction

00:01:44.010 --> 00:01:45.240
under our firm policy.

00:01:45.810 --> 00:01:48.450
This experience taught me that although we have systems in

00:01:48.450 --> 00:01:51.240
place that are designed to help teams get it right, we must

00:01:51.240 --> 00:01:53.850
still be diligent in performing procedures appropriately.

00:01:54.720 --> 00:01:57.030
Had we been more thorough during our review of potential

00:01:57.030 --> 00:02:00.030
matches in Sentinel, we could have exited the impermissible

00:02:00.030 --> 00:02:03.450
services ahead of the acquisition, avoided incurring a

00:02:03.450 --> 00:02:06.450
violation and needing to have a difficult conversation with

00:02:06.450 --> 00:02:09.210
our client’s Audit Committee, potentially damaging the

00:02:09.210 --> 00:02:10.290
valued relationship.