The industry has been treating a filing cycle problem as a productivity problem. Better editors, smarter spreadsheet links, faster XBRL taggers, AI that drafts the MD&A. None of this is wrong on its own terms. It just keeps answering the wrong question.
The right question is about the nature of the object being produced.
There is a tool that most public company finance teams use to manage their 10-K and 10-Q filings. It connects financial data to document text, maintains live links between spreadsheet cells and the words on the page, and lets multiple people edit a shared document at the same time. It is well-built and widely adopted. It materially reduced the error rate from the era when teams re-keyed figures from Excel into Word by hand, and that was a genuine improvement.
And yet the SEC Reporting Lead who uses it still spends most of a filing cycle doing the same things: chasing updated source files over Slack, reconciling figures between three different workbooks, routing redlined Word documents via email, following up to confirm approvals, and assembling an audit trail after the fact from a folder of sent-item exports and screenshots.
The tool did not cause these problems. But it also did not solve them. The gap between what the document tool handles and what the filing process actually requires is what this post is about.
What document tools were built to do
Before platforms like Workiva became the standard in public company reporting, finance teams were running their filing cycles on a combination of Word documents and Excel spreadsheets that had no structural connection to each other. A number would be confirmed in a spreadsheet, typed manually into the Word document, and from that point forward, exist in two separate places with no link between them. When the number changed (which it did, repeatedly, during a close cycle), someone had to remember every place it appeared and update them all by hand. Version control meant dated file names. Review coordination meant email threads. The audit trail was whatever the team could reconstruct afterward.
Document tools solved a specific and real problem within this picture. They made it possible to link document text to underlying data cells, and they made it possible for multiple people to work on the same document at the same time without creating conflicting versions. Those are genuine improvements. They reduced a category of error that was common and consequential.
What they did not attempt to solve, and were not designed to solve, is the process that surrounds the document. A document tool holds a document. It does not hold a process.
What the filing process actually contains
A periodic SEC filing is not one workflow. It is closer to a dozen interlocking ones, all running simultaneously under deadline pressure and all owned, ultimately, by the same person.
There is the roll-forward: taking last period's filing and bringing it forward to the current period, updating dates, refreshing stale numbers, flagging what carried correctly and what needs human review. There is source linking: confirming that every disclosed figure can be traced back to a specific row in a specific system, and detecting when those sources change structure mid-cycle. There is section drafting: distributing pieces of the document to subject-matter owners across the organisation, receiving their contributions in whatever format they arrive, and integrating them into the filing. There is tie-out: walking every number in the financial statements back to its source. There is internal review: routing the draft to the CFO, the controller, legal, and the audit committee, collecting their comments, tracking which have been addressed and getting documented sign-off from each. There is external audit: responding to requests for workpapers, change logs, and support for new disclosures. There is the regulatory compliance check. There is XBRL tagging. And there is EDGAR submission.
Every one of these workflows produces information that the next one needs. The audit trail from tie-out informs the auditor review. The comment resolution from internal review informs the final regulatory check. The source links from the document editor determine what the tie-out workbook can verify. When each workflow runs in a different tool with no shared record between them, the Reporting Lead becomes the integration layer. She is the person who knows what state the filing is in, who has approved what, which sources have been refreshed and which have not, and what changed between last Tuesday's draft and the one going to the auditors this morning. None of that knowledge lives anywhere except in her head and her sent-item folder.
This is not a coordination failure. It is an architectural one. The tools are not broken. They are simply not built for the object she is producing.
What the tools are actually doing
Walk through the stack that shows up in almost every public company filing process and the mismatch becomes specific.
The document editor handles assembly, and it does the assembly part well. What it cannot do is recognise that a particular cell contains a number the CFO will personally certify, log why anyone touched it, or track whether the filing has reached a state where it can be submitted. For the editor, state is a save timestamp.
Excel is doing two jobs the people who built it never anticipated. It serves as the tie-out workbook holding the link between every disclosed number and its source. It also serves as the source of record for a meaningful share of those numbers, including the legal accrual workbook, the tax provision schedule, and large parts of the equity rollforward. When a GL export changes structure between quarters, when someone renames a column or reorganises a tab, Excel says nothing about it. The link breaks silently, the filing displays the old value, and the team finds out at tie-out under deadline pressure. The SEC's Division of Corporation Finance has flagged MD&A inconsistency, unexplained period-over-period figure changes, and cross-reference failures among its most common comment letter triggers for years. Most of these failures do not start in bad judgment. They start in the mechanical fragility of data moving across disconnected tools.
Word handles the redlines. A functional head receives a section by email, edits it with track changes, sends it back, and the Reporting Lead manually integrates the changes into the master document. Version history lives in file names. The Outlook sent folder serves as the audit log.
Email and Slack carry everything else: review routing, approvals, comment resolution, status reporting. None of them produce a record an auditor can later query. When a CFO approves a draft as a reply to a PDF attachment, that approval has no entry in any system of record. When a comment gets resolved in a Slack thread, the resolution leaves no documentation. Three months later, when the auditor asks how a specific footnote was reasoned through, the team rebuilds the trail from memory and search history.
None of these tools are bad at the work they were designed for. They just were not designed for this work, and the difference compounds.
The nature of the object
Most finance leaders think about SEC reporting through an intuitive model: the filing is a document, the team writes the document, and tools exist to help write it faster. Inside that model, every conversation about improving the cycle becomes a conversation about features.
The model is wrong in a specific way.
What gets built every quarter at a public company is closer to a regulated product than a document. It has versioned inputs from multiple source systems, a defined transformation sequence with named state transitions, personal legal certification under Sarbanes-Oxley Sections 302 and 906, and antifraud liability under Rule 10b-5 of the Securities Exchange Act of 1934. Every figure carries weight as a certified fact. Every change to every figure is, in legal terms, a decision that has to be traceable back to a person, a reason, and a moment in time.
A document tool holds the output: the text, the figures, the structure of the page. It does not represent the state of the process: whether the filing is in draft, whether all sources have been confirmed, whether all reviewers have signed off, whether the audit trail is complete. It cannot tell you, at any point during the cycle, whether the filing is ready to proceed to the next stage, because it does not understand that there are stages.
This is the precise limitation. And it is not a criticism of document tools. It is a description of what they were designed for and what they were not.
The person absorbing what the tools cannot
Every public company solves this coordination problem the same way: by quietly absorbing it into the Reporting Lead's job.
She tracks which source files have come in. She flags when a figure moves between drafts. She routes the right version of the right section to the right reviewer. She remembers who approved what. She reconstructs the audit trail when the auditor asks. She holds the state of the entire filing in her head because no software holds it for her.
This is a description of a competent Reporting Lead doing the job as currently constructed. If she stops doing the coordination work for two days during a cycle, the filing falls apart. The role requires this work to happen. It just has nothing to do with disclosure judgment.
What this produces, in practice, is a finance organisation that spends its most expensive technical accounting talent on integration tasks for more than half of every filing cycle. The company is paying for disclosure judgment and getting coordination work in return. Whatever disclosure judgment does happen tends to get squeezed into the back end of the cycle, under fatigue, which is also when judgment quality drops fastest.
Hiring a second Reporting Lead does not fix the problem. It doubles the coordination overhead by creating a second person who has to learn the patchwork well enough to navigate it under pressure, and it adds a synchronisation layer between two humans for a process the software should have been synchronising.
The cost compounds in ways finance leadership tends to miss because each component looks like an execution issue rather than a structural one. The time cost is the most visible. A 10-K cycle runs six to ten weeks, a 10-Q runs four to six, and the actual disclosure judgment inside those cycles takes a fraction of that time. The rest is coordination overhead. The error cost is less visible. Silent link breaks and manual re-keys across disconnected tools are the mechanical origin of many of the disclosure failures the SEC flags in comment letters. PCAOB Auditing Standard 1105 requires audit evidence to be sufficient and appropriate, and a trail reconstructed after the fact from sent folders and screenshots does not sit in the same evidentiary class as a contemporaneous record. Auditors know the difference, and so do the lawyers who arrive later.
What a workspace built for this object would need to understand
A reporting workspace, as distinct from a document tool, would need to understand the filing as a stateful object from the moment the cycle begins to the moment the EDGAR confirmation receipt is captured.
It would need to understand that every figure has a source, and sources move. When the FP&A model gets re-saved on a Monday afternoon, the workspace should already know which document figures depend on it. Each figure should carry a live status, whether confirmed, pending, or changed since last confirmation. Drift should surface as it happens, with a named owner asked to confirm or reject the change. Tie-out, in that world, stops being a discrete event at the back of the cycle and becomes a continuous property of the document.
It would need to understand that a comment is a decision, not a message. When the CFO marks up a risk factor, the markup is a pending change to a document she will personally certify. It belongs in a review queue with status, owner, timestamp, and a recorded resolution. Not because that is more convenient, but because Sarbanes-Oxley Section 302 asks for evidence that disclosure controls operated effectively, and "it was in an email thread" is not that evidence.
It would need to understand that the filing has states, not just versions. A 10-K moves through initialized, sources-linked, drafting, tie-out-complete, controller-reviewed, auditor-cleared, disclosure-committee-approved, and submitted. Each state carries defined entry conditions. The question everyone asks repeatedly during a cycle, which is where the filing currently stands, should have an answer that lives in the system rather than in the Reporting Lead's head.
It would need to understand how AI fits. This is where most current vendor pitches go wrong. A model that drafts a footnote disclosure has produced a proposed change to a document the CFO will sign. That proposal cannot enter the filing until a named human has reviewed it, accepted or rejected it, and logged the decision as part of the trail. This is the governance condition that makes AI outputs defensible under SOX 302. An AI tool applied to SEC filings without this governance layer is not solving the problem. It is adding an ungoverned input to an already ungoverned process.
And it would need to understand that the filing is not finished when EDGAR accepts it. It is finished when the trail is complete. The audit, the comment letter response, the potential restatement review, all of these require a record of how the filing was assembled. That record should exist as a byproduct of normal work, not as a reconstruction exercise that someone runs under pressure months later.
What changes when the environment fits the object
When the environment handles coordination, the Reporting Lead does the work she was actually hired to do.
When the environment tracks sources, she does not discover at tie-out that a workbook changed structure three weeks ago and the linked figures are wrong. The change was detected when it happened and routed for review before it propagated into the disclosure.
When the environment tracks review state, she does not spend Tuesday morning forwarding PDFs and following up on approvals. Each reviewer's section is in a defined state and she sees the complete picture without asking.
When the environment generates the audit trail in real time, the auditors do not receive screenshots and email threads assembled under deadline pressure. They receive a structured record of every source link, every staged change, every comment, every approval, and every AI action, exportable as a single package at any point during the cycle.
The filing cycle does not get shorter because the team works harder. It gets shorter because the coordination work that consumed most of the cycle is handled by the environment, not delegated to a person. What remains is the disclosure judgment that was always the actual job.
The SEC built the continuous disclosure system on a sound premise: that public companies would disclose accurately, completely, and in a way investors could rely on. The environment most companies use to fulfill that obligation was never designed for it. The tools were assembled because they were available when the work needed doing. The premise has held for decades on the strength of the Reporting Lead's effort and the assumption that someone would eventually figure out how to make the tools work together.
The filing has always been a regulated product. The environment for building it is overdue.
