Resubmission of an audit is a process that is not described in Uniform Guidance, but is a process that is prescribed in both Generally Accepted Governmental Auditing Standards (GAGAS) and Generally Accepted Auditing Standards (GAAS).
Uniform guidance is silent on audit resubmission. However, both GAAS and GAGAS speak to the conditions under which an audit report may need to be retracted and resubmitted. Specifically, Responding to Identified Quality Management Deficiencies discusses this, and it references both paragraph 9.68 in that text and AU-C-560; the particular section we are interested in is titled Subsequently Discovered Facts That Become Known to the Auditor After the Report Release Date (AU-C §560.15).
Put simply, auditors and auditees need to be able to resubmit audits.
Who is resubmitting, and why?
There are at least four reasons an audit might be resubmitted:
Auditor/auditee|immaterial. It is possible the auditor or auditee wishes to correct aspects of their submission of an immaterial nature, but for overall correctness of the record, they wish to undertake the resubmission of their prior submission.
Auditee|material. It is possible the auditee discovers information after the report is submitted that changes the scope, evidence, or results of the audit. As a result, the audit will need to be resubmitted.
Auditor|material. It is possible that the auditor has discovered additional information or a serious departure from auditing standards that requires additional work and the resubmission of the previously submitted audit.
Government|material. As a result of government Single Audit oversight activities, the auditor and/or the auditee has been alerted to a material quality issue that compromises the reliability of the audit for at least one of the intended users. An audit resubmission would be required to correct the material quality issues identified by the Federal oversight agency.
When resubmitting an audit, it effectively nullifies the previous report. From the auditor’s perspective, the prior report should no longer exist according to auditing standards from the public’s point-of-view.
From the Federal government’s perspective, the original audit is now Federal data, collected under retention laws. Further, the differences between one audit report and another can matter a great deal to resolution officials.
Workflow
Decision
What follows is a suggested resubmission workflow. In all cases, reference to the auditor implies the Auditor Certifying Official, and likewise for the auditee.
Either auditor or auditee may initiate the resubmission process.
The FAC alerts both parties, who must both positively acknowledge, at the FAC, that they approve the resubmission of this audit.
The audit is unlocked for resubmission.
The audit is submitted to the FAC as if it was a complete, new submission.
Possible additional data collection (see below).
The auditor certifies.
The auditee certifies.
The FAC links the original report and the new report.
As part of this resubmission process, we likely want to ask at least two questions:
What is the reason for resubmission?
This might be a list of options to choose from, including “other.”
What is a summary (in 200 words or less?) of the changes made to the audit report.
Additional work with IGs will be necessary to determine the nature of the information collected at this point.
Consequences
A public user of the FAC will see the accepted date and resubmitted date, but will only find the most recent record.
For authenticated Federal users, the result of linking audits will allow the FAC to present something akin to the view presented below:
The Clearinghouse can maintain:
The original acceptance date
The date that the audit was resubmitted
(When viewed by a Federal official) a link from the resubmitted audit to the original audit.
If a report is resubmitted three, four, or more times, a complete linkage history can be maintained.
A given report can only be resubmitted once
A given report should only be able to be resubmitted once. E.g.
A->B->C
is a valid resubmission sequence.
A->B and A->C
where A is resubmitted once as B, and again as C, is not valid.
[!NOTE]
The side-effect of implementing resubmission is that we will only allow one submission for a given UEI per audit year. Any subsequent submissions must necessarily be resubmissions, and we can direct users to that workflow.
We are aware there are exceptions to this rule (e.g. biannual audits); those exceptions must be unpacked and accounted for.
Further investigation with State Auditors is warranted here.
Our current numbers suggest that resubmissions happen at a rate of approximately 1-2% of all audits; most appear to be legitimate resubmissions. Some may be incorrect submissions for multiple entities under one UEI.
Dates, dates, and more dates
The FAC is not in the space of assessing risk.
OMB will provide clear guidance to agencies regarding:
The FAC acceptance date
The resubmitted date(s)
It is our expectation that OMB will establish guidelines regarding the application of the following:
For most submissions, the FAC acceptance date will be used to determine the timeliness of the audit submission with regards to the 30-day and 9-month deadlines. OMB will provide guidelines for resubmission timelines.
In the case of a resubmission, the date of the resubmission will be used to determine what the government’s 6-month clock is for purposes of resolution.
Implementation stories
What follows are high-level stories to drive the ticketing and implementation of resubmission.
Resubmission 1
[!IMPORTANT]
An authenticated uiser initiates the resubmission of an audit.
Any authenticated user can initiate the resubmission of any audit.
While the exact implementation mechanism may vary slightly, a user should be able to identify the report they wish to resubmit via report id.
This means we can only resubmit reports we have in the system. At this time, we have no way to resubmit a report from 2015 or prior. It will have to be a new submission.
[!WARNING]
We need to have an SOP or other mechanism for connecting people to older audits where resubmission is requried.
[!NOTE]
As part of this process, we may need to have a step where the user(s) attest that they have the legal right to initiate a resubmission of this audit.
An auditee may be a new certifying official in their organization, and have no (in-system) connection to a prior audit report.
An auditing firm may have a new certifying official.
Resubmission 2
[!IMPORTANT]
Both the Auditor Certifying Official and Auditee Certifying Official must agree to a resubmission.
There should be a positive confirmation from both officials at the start of the resubmission process.
If either certifying official changes between one submission and the next, a flag should be added to the resubmission record.
Resubmission 3.1
[!IMPORTANT]
A submitter working on a resubmission is responsible for re-entering and re-uploading all portions of a Single Audit.
A resubmission is a new submission.
A submitter may obtain the SF-SAC and SAR from their disseminated audit. In this regard, they have all of the data they need in order to recreate their audit. They may, or may not, have retained their original submission materials. (They are told and expected to.)
[!WARNING]
Tribal reports may, or may not, be suppressed.
The FAC should provide a warning, as part of the cross-validation process (before certification) if a resubmission changes the status of an audit from suppressed to public from one resubmission to the next.
The Tribe or Tribal Organization may make this change, but we should alert on any change in case the entity did not intend to change the status of their report as part of the resubmission process.
Resubmission 3.2
[!IMPORTANT]
A resubmission can update the UEI, audit year, and auditee type.
Currently, this is not possible. However, those are errors that could have been made, and a resubmission is necessary. We need to allow these values to be updated after the time of audit creation.
Or, we should consider a separate mechansim by which general information about the audit can be "fixed." This would allow us to encourage resubmission only in the case of material changes, and handle resubmissions to repair minor SF-SAC changes separately.
Constraint 3.2
[!IMPORTANT]
Disallow duplicate UEI-audit year submissions.
Resubmissions should be the only pathway to create an additional report with a UEI-audit year that already exists.
In the case of a UEI and/or audit year change, we would disallow future (new) submissions against only the most recent resubmission’s UEI/audit year, not the prior.
If we must allow this, it may be we want to consider it a kind of validation exception, until such time as we can assert all entities must submit under unique UEIs.
Resubmission 3.3
[!IMPORTANT]
A resubmission must capture additional metadata regarding the what and why of the resubmission.
This information will be accessible to Federal officials.
Resubmission 4.0
[!IMPORTANT]
Every report gets a unique report ID.
Lewiston School District #1 (LSD), in completing its audit, has a unique report ID:
that makes clear that it has been removed, and B is now the authoritative report.
Resubimssion 4.1
[!IMPORTANT]
Public users searching the FAC find only the most recent version of an audit report.
As a public user, I may have bookmarked or otherwise am keeping track of this audit report. I might be Lewiston Public Schools, and have this URL handy for one reason or another.
After a resubmission, a public user (and likely Federal officials) will still know this report as being at that URL. So, the public user should find a page that has the original report metadata (date submitted, entity name, etc.), but no links to an SF-SAC or audit report. Instead, it should note on the page that the report was resubmitted, and a link to the new report be provided.
Using the example above, a visitor to the page for submission A should have a clear way to get to B as the resubmitted report. A public user cannot download the SAR or SF-SAC for A. Further, a public user should not be able to intentionally search for A. Searches should only turn up B.
Resubmission 4.2
[!IMPORTANT]
Federal users searching the FAC find only the most recent version of an audit report.
Resolution officials want to flip back-and-forth between (say) corrective action plans, or financial info. Therefore, it is the same as above, but the SF-SAC and report are available, along with a clear pointer to the resubmission.
Therefore, a Federal user needs to be able to find the resubmitted report and navigate to the original report.
Using the above example, imagine that Submission A is submitted on 5/1. A Federal user searching for audits in the range 04/15-05/15 will find Submission A.
Now, imagine there is a resubmission (A->B), and it is resubmitted as Submission B on 6/1.
At this point, a search for audits in the accepted date range of 4/15-5/15 will turn up nothing. A search in the range 5/15-6/15 will turn up submission B.
API considerations
This ADR does not address the API. However, how resubmitted audits do (or do not) appear in the API must be addressed.
Areas of impact
Related documents/links
Context
Resubmission of an audit is a process that is not described in Uniform Guidance, but is a process that is prescribed in both Generally Accepted Governmental Auditing Standards (GAGAS) and Generally Accepted Auditing Standards (GAAS).
Uniform guidance is silent on audit resubmission. However, both GAAS and GAGAS speak to the conditions under which an audit report may need to be retracted and resubmitted. Specifically, Responding to Identified Quality Management Deficiencies discusses this, and it references both paragraph 9.68 in that text and AU-C-560; the particular section we are interested in is titled Subsequently Discovered Facts That Become Known to the Auditor After the Report Release Date (AU-C §560.15). Put simply, auditors and auditees need to be able to resubmit audits.
Who is resubmitting, and why?
There are at least four reasons an audit might be resubmitted:
When resubmitting an audit, it effectively nullifies the previous report. From the auditor’s perspective, the prior report should no longer exist according to auditing standards from the public’s point-of-view.
From the Federal government’s perspective, the original audit is now Federal data, collected under retention laws. Further, the differences between one audit report and another can matter a great deal to resolution officials.
Workflow
Decision
What follows is a suggested resubmission workflow. In all cases, reference to the auditor implies the Auditor Certifying Official, and likewise for the auditee.
As part of this resubmission process, we likely want to ask at least two questions:
Additional work with IGs will be necessary to determine the nature of the information collected at this point.
Consequences
A public user of the FAC will see the accepted date and resubmitted date, but will only find the most recent record.
For authenticated Federal users, the result of linking audits will allow the FAC to present something akin to the view presented below:
The Clearinghouse can maintain:
If a report is resubmitted three, four, or more times, a complete linkage history can be maintained.
A given report can only be resubmitted once
A given report should only be able to be resubmitted once. E.g.
A->B->Cis a valid resubmission sequence.
A->BandA->Cwhere
Ais resubmitted once asB, and again asC, is not valid.Dates, dates, and more dates
The FAC is not in the space of assessing risk.
OMB will provide clear guidance to agencies regarding:
It is our expectation that OMB will establish guidelines regarding the application of the following:
Implementation stories
What follows are high-level stories to drive the ticketing and implementation of resubmission.
Resubmission 1
Any authenticated user can initiate the resubmission of any audit.
While the exact implementation mechanism may vary slightly, a user should be able to identify the report they wish to resubmit via report id.
This means we can only resubmit reports we have in the system. At this time, we have no way to resubmit a report from 2015 or prior. It will have to be a new submission.
Resubmission 2
There should be a positive confirmation from both officials at the start of the resubmission process.
If either certifying official changes between one submission and the next, a flag should be added to the resubmission record.
Resubmission 3.1
A resubmission is a new submission. A submitter may obtain the SF-SAC and SAR from their disseminated audit. In this regard, they have all of the data they need in order to recreate their audit. They may, or may not, have retained their original submission materials. (They are told and expected to.)
Resubmission 3.2
Currently, this is not possible. However, those are errors that could have been made, and a resubmission is necessary. We need to allow these values to be updated after the time of audit creation.
Or, we should consider a separate mechansim by which general information about the audit can be "fixed." This would allow us to encourage resubmission only in the case of material changes, and handle resubmissions to repair minor SF-SAC changes separately.
Constraint 3.2
Resubmissions should be the only pathway to create an additional report with a UEI-audit year that already exists.
In the case of a UEI and/or audit year change, we would disallow future (new) submissions against only the most recent resubmission’s UEI/audit year, not the prior.
If we must allow this, it may be we want to consider it a kind of validation exception, until such time as we can assert all entities must submit under unique UEIs.
Resubmission 3.3
This information will be accessible to Federal officials.
Resubmission 4.0
Lewiston School District #1 (LSD), in completing its audit, has a unique report ID:
Submission
A: https://app.fac.gov/dissemination/summary/2023-06-GSAFAC-0000018567The resubmission will be a new submission with a new report ID.
Submission
B: https://app.fac.gov/dissemination/summary/2023-06-GSAFAC-0000031234If
Ais resubmitted, then the page for that report should display information in keeping withhttps://gaoinnovations.gov/yellowbook/2024/discovery-of-insufficient-evidence-after-report-release.html#section-9.68
that makes clear that it has been removed, and
Bis now the authoritative report.Resubimssion 4.1
As a public user, I may have bookmarked or otherwise am keeping track of this audit report. I might be Lewiston Public Schools, and have this URL handy for one reason or another.
After a resubmission, a public user (and likely Federal officials) will still know this report as being at that URL. So, the public user should find a page that has the original report metadata (date submitted, entity name, etc.), but no links to an SF-SAC or audit report. Instead, it should note on the page that the report was resubmitted, and a link to the new report be provided.
Using the example above, a visitor to the page for submission
Ashould have a clear way to get toBas the resubmitted report. A public user cannot download the SAR or SF-SAC forA. Further, a public user should not be able to intentionally search forA. Searches should only turn upB.Resubmission 4.2
Resolution officials want to flip back-and-forth between (say) corrective action plans, or financial info. Therefore, it is the same as above, but the SF-SAC and report are available, along with a clear pointer to the resubmission.
Therefore, a Federal user needs to be able to find the resubmitted report and navigate to the original report.
Using the above example, imagine that Submission
Ais submitted on 5/1. A Federal user searching for audits in the range 04/15-05/15 will find SubmissionA.Now, imagine there is a resubmission (
A->B), and it is resubmitted as SubmissionBon 6/1.At this point, a search for audits in the accepted date range of 4/15-5/15 will turn up nothing. A search in the range 5/15-6/15 will turn up submission
B.API considerations
This ADR does not address the API. However, how resubmitted audits do (or do not) appear in the API must be addressed.