The thesis: the audit is now asking a question your integration layer can answer.
Most audit standards land on the audit firm and reach the company only as a longer request list. This one is different in a useful way. Paragraph .10A of AS 1105 asks the auditor to evaluate the reliability of information the company hands over that the company itself received from an outside source, and the evaluation explicitly covers the company’s process for receiving, maintaining and, where relevant, processing that information. Read that again as an ERP person rather than an audit person. The subject of the requirement is your integration layer.
That makes the readiness work unusually concrete. There is no filing, no attestation and no new disclosure. There is a description of how data gets from a bank, a vendor, a custodian or a tax authority into your ledger, and evidence that the description is accurate. A finance team that can produce that description quickly is going to have a cheaper audit than one that reconstructs it from memory each January, and the gap will widen every year the same register gets reused.
What changed, and when it starts to bite.
The PCAOB adopted its technology-assisted analysis amendments on June 12, 2024 as Release No. 2024-007, updating AS 1105, Audit Evidence, and AS 2301, The Auditor’s Responses to the Risks of Material Misstatement. The SEC approved them on August 20, 2024. They apply to audits of financial statements for fiscal years beginning on or after December 15, 2025, which puts a calendar-year company inside the first year in scope right now, with interim procedures and process walkthroughs happening during 2026 and the first year-end under the rule still ahead.
The amendments do several things at once. They clarify what a test of details covers for each item selected, they set out the auditor’s responsibilities when a procedure serves more than one purpose, and they spell out what happens when technology-assisted analysis flags items for further investigation, which is that the auditor has to determine whether those items, alone or together, point to a misstatement or a control deficiency. They also put more weight on IT controls and on having information at an appropriate level of detail. Woven through all of it is the new paragraph .10A, and that is the one with a direct line into finance systems.
Paragraph .10A applies when the company gives the auditor information in electronic form that the company received from one or more external sources. The auditor has to evaluate whether that information is reliable for audit purposes, first by understanding the source and the company’s process by which the information was “received, maintained, and, where applicable, processed”, including the nature of any modifications made before handover, and second by either testing the information for modification and evaluating the effect, or testing the controls over receiving, maintaining and processing it, including IT general controls and automated application controls where relevant. A footnote gives the everyday examples: cash receipts, shipping documents, purchase orders. None of those are exotic. All of them move through an ERP.
Three paths in, three different amounts of audit work.
In October 2025 the PCAOB’s Office of the Chief Auditor published worked examples of applying paragraph .10A. Taken together they form a ladder that is genuinely useful for design, because the amount of audit work rises with how much the company’s own systems touch the data on the way in.
| Path | Worked example | What makes it that path | What the audit has to do |
|---|---|---|---|
| Stored exactly as received | Electronic vendor invoices sent by the vendor and uploaded into an internal repository without processing or modification | Lower risk of material misstatement, each item individually less important, no modification in the path | Under the Board policy statement, staff will not recommend treating the absence of separate testing as noncompliance where the possibility of a reliability-affecting modification is no more than remote |
| Converted and posted into the ERP | Daily cash receipts arriving on an automated bank feed, converted into a format the ERP can record, then maintained there | The information is processed by the company’s own systems before the auditor sees it | Testing is necessary. The auditor either compares a selection back to the electronic bank statements, or tests controls over receiving, maintaining and processing the feed, including IT general controls and automated application controls |
| Downloaded and rekeyed by a person | Statutory income tax rates downloaded each quarter, manually input into the tax information system, then extracted into a file for the auditor | A human step sits between the outside source and the file handed over | Substantive work can carry it. Recomputing against the rates published by each taxing authority addresses the objective without a separate testing step |
The middle row is where most finance teams actually live. An automated bank feed converted into a format the ERP can record, and then maintained inside the ERP, is processed information by definition, and the guidance is direct that testing is necessary in that scenario. The good news sitting inside that conclusion is the word or. The auditor can test the data by comparing a selection back to the electronic bank statements, or test the controls over the interface. If your IT general controls and automated application controls over that feed are already documented, already tested for other reasons, and already reliable, the second route is available and it is usually the cheaper one for everybody.
The deferral request, and what came instead.
This is worth knowing because it changes how you plan. On July 23, 2025 the Center for Audit Quality wrote to the PCAOB asking for a one-year deferral of paragraph .10A, together with clarifying guidance or targeted amendments. Its argument was that the requirement lacked sufficient clarity for successful implementation and risked significant unnecessary costs without commensurate benefit. That is a serious request from a serious body, and it is easy to see how a finance team hearing about it second hand would conclude the date had moved.
It did not. The Board kept the effective date and answered the substance a different way. On September 18, 2025 it issued a policy statement describing circumstances in which the absence of separate testing under paragraph .10A(b) will not be treated as noncompliance, keyed to the auditor’s risk assessment, the importance of the information used, and the results of other audit procedures. Two weeks later the staff guidance arrived with the examples. The practical effect for a company is that the timeline stands and the relief is conditional, so the register is still worth building.
The first staff example shows the conditional relief working. Where operating expenses carry a lower assessed risk, each invoice is individually less important, the process is not complex, and the company does not modify the invoices it receives, the auditor can conclude there is no more than a remote possibility of a modification that would make them unreliable, and staff will not recommend that the absence of separate testing be treated as noncompliance. Notice how much of that conclusion depends on facts a finance team controls: whether the process is simple, and whether anything was changed.
The register worth building once.
The artifact that answers all of this is not complicated. It is an inventory of external data sources with the ingestion path described for each one. Most of the content already exists, scattered across interface documentation, a SOX control matrix, and the heads of two or three people. Putting it in one place is the whole exercise.
Source identifier
The outside party the data originates from, named the same way it is named in the vendor, bank, or counterparty master record rather than by the name of the file.
Arrival channel
Automated feed, API, portal download, secure file transfer, or email attachment, since the channel is the first thing an auditor will ask you to describe.
Financial statement area
The account or assertion the data ultimately supports, so the register can be filtered to whatever the audit scope turns out to be.
Processing on the way in
Whether the data is stored as received, reformatted, enriched, mapped, deduplicated, or rekeyed, stated plainly per step rather than summarised as loaded.
Original file retention
Whether the file exactly as the outside source sent it is still retrievable, and for how long, which is what makes a comparison back to source possible at all.
Controls over the path
The named IT general controls and automated application controls that cover the interface, with their control identifiers from the existing SOX or internal control matrix.
Independent recomputation source
Whether the same fact can be obtained from a public or third-party source, which is what let the tax rate example in the staff guidance resolve without extra testing.
Path owner
The person accountable for the interface itself, so a question about a transformation goes to a named owner rather than to whoever answered last year.
Example register row for one external data source
{
"source_id": "src-bank-primary-eur",
"external_party": "Primary operating bank, EUR accounts",
"arrival_channel": "automated_daily_feed",
"financial_statement_area": "cash, accounts receivable application",
"processing_on_the_way_in": [
"format_conversion_to_erp_layout",
"entity_and_account_mapping",
"duplicate_suppression"
],
"original_file_retained": true,
"original_retention_months": 84,
"controls_over_path": ["ITGC-CHG-04", "ITGC-ACC-11", "AAC-CASH-02"],
"independent_recomputation_source": "monthly electronic bank statement",
"path_owner": "Integration lead, finance systems",
"last_walkthrough": "2026-08-04"
}The two fields that do the most work are the list of processing steps and the retention of the original file. The first turns a vague answer into a specific one. The second is what makes the comparison route possible at all, because you cannot test whether data was modified if the version as delivered is gone.
Implementation checklist.
Build the inventory before the auditor asks for it. List every external source whose data reaches the ledger, name its arrival channel, and record which financial statement area it supports, because the first request under paragraph .10A is a description of the path rather than a sample.
Write down each transformation between arrival and posting, step by step. Reformatting, currency mapping, entity mapping, deduplication and rounding all count, and a path described as loaded into the ERP will not answer the question.
Retain the original file exactly as the outside source delivered it, alongside the processed version. The staff guidance example that resolved most cheaply is the one where nothing was modified, and the comparison route only exists if the unmodified copy survives.
Map each ingestion path to named IT general controls and automated application controls in the control matrix you already maintain, since testing controls is the alternative the standard offers to testing the data itself.
Flag the paths where an independent source can recompute the same fact, such as published statutory rates or exchange rates, because substantive work against that source can address the objective without a separate testing step.
Ask your auditor now, during interim planning, which sources they consider external information provided by the company for this year. The list is usually shorter than a finance team expects and longer than an integration team expects.
Give reconciling and exception items a reason code at the point they arise, since technology-assisted analysis over a full population produces a list of items to investigate, and every unexplained item becomes a conversation about whether it indicates a misstatement or a control deficiency.
Treat a manual spreadsheet step in an ingestion path as a finding for your own register even when nobody has asked about it, and decide deliberately whether to control it or to remove it before year-end.
Sequence it by materiality. Cash and receivables feeds first, since those are the paths with the most volume and the most direct line to a balance an auditor will test in detail. Tax rate tables, price feeds and reference data can follow, and several of them will turn out to sit in the third row of the ladder where an independent published source settles the question quickly.
Constructive failure modes to design around.
Assuming the requirement lands only on the audit team. The evaluation covers the company’s own process for receiving, maintaining and processing the information, so the answers live with the people who own the interfaces.
Handing over an extract that has already been filtered, sorted or reformatted for convenience, then having no unmodified original to compare it against when the auditor asks what changed.
Describing an ingestion path at the level of the system name. An answer of it comes in from the bank does not tell an auditor whether the data was modified between the bank and the ledger.
Reading the September 2025 policy statement as a general exemption. It describes specific circumstances, tied to the risk assessment and the importance of the information, rather than a blanket answer for every feed.
Leaving the register to the first year and letting it drift after that. Interfaces change quietly, and a description that was accurate at the last audit is the kind of thing that fails on the second pass.
Waiting for the year-end request. Interim is when walkthroughs of these processes happen, and a source inventory produced in January is worth less than the same inventory produced now.
The CAQ’s concern about cost was reasonable, and the honest version of it is that a company with undocumented ingestion paths will spend real money answering these questions the first time. The same work done once, and maintained, gets cheap. That is the argument for doing it on your own schedule during interim rather than under year-end pressure.
What to ask ERP and integration vendors now.
Can the platform retain the original inbound file exactly as received, alongside the processed record, and retrieve the pair on demand for a given period?
Does it produce an audit trail of the transformations applied to inbound data, at the level of individual steps rather than a job success flag?
Are the automated application controls over each inbound interface documented in a form that maps to control identifiers in an existing control matrix?
Can it report a full population of inbound records for a period, with the exceptions and their reason codes attached, rather than only the posted results?
Does the integration layer record which outside source each record came from, so a question about one bank or one vendor can be answered without tracing files by hand?
A platform that keeps the inbound original, logs each transformation, and can hand back a full population with its exceptions has already built what this requirement rewards. The remaining judgment, which sources are in scope and how much testing each one needs, stays a conversation between the finance team and the auditor, which is where it belongs.
Practical takeaway.
The first audits under the technology-assisted analysis amendments are being planned now, and the requirement that reaches furthest into finance systems is a question about plumbing: where did this data come from, what happened to it on the way in, and can you show that. Answer it with a register rather than an email thread and the audit gets easier in the first year and easier again in the second. The most valuable thing a finance team can do this quarter costs almost nothing: write down the paths, keep the originals, and point each interface at a control that already exists.
Sources.
- PCAOB: AS 1105, Audit Evidence
- PCAOB Release No. 2024-007: Amendments Related to Aspects of Designing and Performing Audit Procedures that Involve Technology-Assisted Analysis of Information in Electronic Form (June 12, 2024)
- PCAOB implementation resources: technology-assisted analysis amendments, including effective date
- PCAOB staff guidance: Examples of Evaluating the Reliability of External Information Provided by the Company in Electronic Form (October 2025)
- PCAOB news release: Board Policy Statement on Evaluating the Reliability of External Electronic Information Provided by the Company (September 18, 2025)
- PCAOB news release: staff guidance providing examples of the application of paragraph .10A of AS 1105
- Center for Audit Quality: letter to the PCAOB requesting deferral of the effective date of certain aspects of the technology-assisted analysis amendments (July 23, 2025)
- SEC press release: approval of new and updated PCAOB audit standards (August 20, 2024)
- Journal of Accountancy: PCAOB publishes guidance related to audit evidence amendments
Targeted searches for public X and Twitter commentary on paragraph .10A of AS 1105, the technology-assisted analysis amendments, and the September 2025 policy statement returned only regulator publications, professional-body letters and trade-press coverage, short of a credible set of two to four high-signal posts from a regulator or an independent practitioner. Ordinary citations are used instead, and nothing here is fabricated.