How Financial Filings Became Data

From paper disclosure to public access

Modern securities disclosure was conceived long before anyone imagined downloading an annual report. In the United States, the reforms following the 1929 market crash established the principle that investors should receive material information about securities offered to them. The Securities Act of 1933 ↗ dealt principally with offerings; the Securities Exchange Act of 1934 created the SEC and a broader framework of continuing oversight and disclosure. The premise was not that the government could certify good investments, but that people should be equipped to judge for themselves.

For decades, access depended as much on distribution as on legal rights. A report could be publicly filed and still be expensive or inconvenient to obtain. Investors with researchers, libraries, printers and established information suppliers had advantages over anyone trying to work from a modest office—or a kitchen table.

Electronic filing began to change that. The SEC's EDGAR system ↗ became operational in 1993 ↗, and domestic companies moved into mandatory electronic filing in phases through 1996. But even here the question of access needed an argument.

In August 1995, internet pioneer Carl Malamud wrote to the US Secretary of Commerce ↗ to announce that his nonprofit would soon stop giving away electronic government documents. It had distributed more than 4.7 million SEC and patent records free over nineteen months. Malamud's point was that the public should not have to depend on a privately funded demonstration to read public records. In the same letter, he contrasted a freely available Microsoft annual report with the $622 that he said a commercial service charged for it. By late September, the SEC had inaugurated its own website with free EDGAR access ↗.

That episode is worth remembering not because free access is now exceptional, but because it has become so ordinary. The modern argument about filings largely takes this achievement for granted. We assume that the documents can be found. We want software to do something useful with them.

Unfortunately, a document delivered electronically is not necessarily data in a form that software can interpret. A program can fetch a financial report without knowing whether a number represents revenue, cash flow, debt or the share of sales from a particular subsidiary. Someone must still work that out—or provide the information in a more explicit form.

The accountant and the markup language

In 1998, Charles Hoffman ↗, an American certified public accountant, began experimenting with XML, the emerging technology for attaching structure to electronic information. His question was a practical one: why couldn't financial statements be transmitted with descriptions of what their figures meant?

Under the traditional approach, a reported number was inseparable from its presentation. Its meaning came from the caption above it, the column beside it, the footnote below it, and the accounting framework surrounding the report. Hoffman imagined attaching some of that context directly to the data so a machine could identify and exchange it.

The idea attracted support from the American Institute of Certified Public Accountants and grew into an international standards effort. What became XBRL—eXtensible Business Reporting Language—was publicly launched in 2000, with an initial specification issued that year. It was less glamorous than the internet's consumer innovations, and potentially more consequential for anyone who spent their days converting financial statements into spreadsheets.

An XBRL fact could carry a recognized concept, a reporting period, a unit and information about the entity or business dimension it described. Taxonomies supplied dictionaries of reporting concepts and their relationships. In principle, software could collect a company's reported facts without having to guess their meaning from the layout of a page.

But XBRL was not a universal chart of accounts that eliminated local judgment. It was an extensible framework, which is part of what made it useful. Different reporting rules required different concepts. Companies had disclosures that could not always be represented by an existing standard label. Local systems could extend or adapt the taxonomies. Making the system expressive enough for real reporting also made uniform comparison more complicated.

Regulators understood both sides of the trade-off. When the SEC established a voluntary XBRL filing programme in 2005 ↗, the tagged exhibits were explicitly experimental. The Commission said investors should continue relying on the official filing, not the XBRL exhibit, in making investment decisions. An initiative designed to make reported information easier to analyze began with a warning not to depend on its new representation.

That caution was reasonable. The voluntary submissions tested the format and the preparers' ability to use it; they did not replace the legally operative documents. Yet the warning captured a problem that still matters: once a filing has been transformed into a data product, somebody needs to verify what survived the transformation.

Mandatory requirements followed. In 2009 the SEC adopted phased rules for interactive financial reporting ↗. In 2018 it adopted Inline XBRL ↗ for operating-company financial statements, moving toward a model in which tagged information could sit inside the human-readable report rather than in a separate exhibit. People and machines were finally being asked to read the same document, albeit in different ways.

By then, XBRL had already become an international story.

The global race had no single starting gun

The early adopters of structured reporting were not all American. In several Asian markets, officials were already moving from electronic documents toward tagged financial data while the SEC was still testing its approach.

South Korea had launched DART ↗, its electronic disclosure system, in 1999. By 2001 it had eliminated offline filing, and in October 2007 it introduced an XBRL disclosure system based on Korean GAAP. A Korean-IFRS-based system followed in 2010. Today DART's official history traces a succession of improvements: consolidated submissions, online search, an open API in 2013, and a newer Open DART service in 2020. The project was as much about reorganizing how companies filed information as it was about data tags.

Singapore, too, was an early adopter. Its Accounting and Corporate Regulatory Authority ↗ introduced XBRL filing requirements and a filing tool in 2007. Unlike a scheme confined to public-market issuers, this was a corporate-registry initiative. Subsequent rounds of consultation and new preparation software were meant to make the requirements more workable for the companies supplying the information. The local objective mattered: the same technology could serve company administration and business reporting, not just equity analysis.

Japan's 2007 rehearsal and 2008 EDINET launch belonged to this early period. The agency's announcement anticipated machine-readable financial statements from thousands of corporate and fund filers, using a Japanese-GAAP taxonomy. Its internal record of complaints about manuals and filing effort is a useful reminder that every efficiency promised to downstream data users has to be paid for somewhere in the reporting process.

The United States was pursuing its own phased programme. India then mandated XBRL filing ↗ for specified classes of companies from the 2010–11 reporting year. Its original 2011 circular included listed companies and subsidiaries as well as companies above defined size thresholds. Different financial-statement populations were being brought into structured reporting under different legal systems.

Britain took a route that can be missed if one looks only at stock exchanges. From April 2011 ↗, company tax returns were required to be submitted online, with accounts and computations generally filed in iXBRL. This was tax administration, with its own taxonomy requirements, rather than a simple equivalent of the SEC's investor-facing filings. The same technological family was being used to satisfy a different institutional purpose.

These initiatives shared an aspiration: move facts out of documents that only people could reliably decipher and into a form that software could use. Yet what they required companies to report, how the reports were identified, what historical records were available and how developers accessed them remained determined locally.

The distinction becomes clearest in Europe. Under the European Single Electronic Format, or ESEF ↗, annual financial reports covered by the rules are prepared in XHTML; issuers with IFRS consolidated financial statements tag that information using Inline XBRL. Detailed tagging applies to the primary statements, while larger blocks of information in the notes have required tagging since 2022. This gives many European annual reports a common electronic reporting format across national markets.

It does not mean they all arrive through one European filing website. That is a separate problem, one the European Union is still addressing.

The world's filings in 2026

It is now possible to build a remarkably sophisticated financial research system entirely from disclosures issued by public authorities. The SEC offers large volumes of searchable filings and structured financial data. EDINET and DART have mature electronic reporting systems. Europe has advanced a cross-border reporting format. National registries and exchanges maintain their own archives and search services. Much of this infrastructure would have seemed extraordinary to a researcher twenty-five years ago.

Try to use several of those systems in the same research project, though, and the remaining gaps become apparent.

Consider a developer building a historical collection of filings for companies in the United States, Japan, South Korea and Hong Kong. In the first market, the natural starting point might be an SEC central index key. In the others, the developer encounters different entity identifiers, filing classifications, language conventions and document packages. Some retrieval paths are API-oriented. Others involve websites and document downloads. Even the meaning of a company's latest annual filing must be determined within the rules of each source.

Hong Kong offers a useful counterpoint to the idea that electronic reporting now simply means XBRL. Its listed-company disclosure site ↗ has long served annual reports, circulars and announcements in formats including PDF, Word, Excel and web pages. The information is accessible and official, but a universal workflow has to account for those formats rather than assume every regulator exposes the same structured facts.

There are deeper differences. A financial year's end is not the date on which a report became public. Submission, acceptance, publication and amendment timestamps can all matter, particularly in point-in-time research. An analyst reconstructing what was knowable on a given date needs to preserve those distinctions, not collapse them into a convenient column called date.

Standards are no complete cure for comparability either. A taxonomy identifies accounting concepts within a reporting framework; it does not abolish the framework or the business choices behind the accounts. Segment definitions change. Companies restate earlier periods. A disclosure can be presented in a new section, described under a revised label or reported on a different basis. Two legitimately tagged facts can still be poor substitutes for one another in a research model.

The IFRS Foundation's continuing work on digital taxonomies ↗ acknowledges the problem at the level of implementation. It publishes guidance for regulators on how to use taxonomies without sacrificing cross-border comparability. Differences in local extensions and filing-system choices have consequences for users who try to assemble a coherent global dataset. The foundation's 2026 guidance ↗ is a reminder that taxonomies are maintained infrastructure, not a one-off conversion exercise.

Europe's next project makes the point especially well. ESEF addresses the format of annual financial reports. The European Single Access Point, or ESAP, addresses the access to information held across collection bodies. In July 2026, ESMA began gathering information ↗ from national authorities and other designated mechanisms for the first phase of ESAP. Public access is scheduled for July 2027 ↗, with more categories to be added afterward.

In other words, Europe has had years of coordinated digital-reporting requirements and is still building a common route by which the public can obtain the resulting information. That is not evidence that the earlier standards were wasted. It shows that a reporting language, a regulatory obligation and a distribution system are different pieces of machinery.

None of these differences is automatically a defect. Korea has its own disclosure framework. Britain's corporate tax system has different needs from the US securities regulator. European common standards must coexist with national mechanisms and legal responsibilities. Standardization can reduce avoidable friction without making those institutions identical.

Still, the friction is real. Anyone who has tried to reproduce a cross-border financial analysis will recognize the hours spent matching entities, chasing attachments, decoding reporting periods, revisiting broken links or discovering that an apparently identical metric was defined differently two years earlier. The glamorous part of financial research rarely begins with a request header or a document identifier. But much of the work depends on getting those details right.

What should remain difficult

The history of machine-readable filings is, on balance, a success. It made public information easier to distribute, extract and analyze at a scale unimaginable when disclosure meant delivering paper documents to a government office. XBRL and iXBRL brought useful structure to financial reporting. Their continued development has helped turn accounting data into material that software can work with directly.

What they have not done—and were never wholly designed to do—is make the interpretation of financial evidence automatic.

A change in operating cash flow might be explained by working capital, business mix, one-off payments or a revision to the reporting perimeter. A new revenue line can signal genuine growth, a reclassification or simply a different presentation. Those questions require analysis of the report, its notes and its history. The correct tag is an excellent starting point, but it is not a conclusion.

There is also work that ought to become much less difficult. Looking up a reporting entity, finding the relevant filing, retrieving the original documents and recording where they came from should not demand a fresh piece of infrastructure for every market.

At SourceState, we've spent a great deal of time working with primary financial disclosures. Some of the hardest problems are analytical. Others are unglamorous repetition: each market has to be approached on its own terms before the research can even begin.

That is the motivation for OpenCorpFilings, the open-source Python library we've built to make public-company filing discovery and retrieval more consistent across regulatory systems. It is an access layer, not a universal translator of accounting meaning. Its current supported markets and limitations are documented with the project, and the original sources remain authoritative.

We chose to open-source that part because reliable access is useful to far more people than those who will ever use SourceState's own research products. Developers and researchers should be free to build their own tools on top of public disclosures without repeatedly solving the same elementary retrieval problems.

There will still be plenty left to argue about once the documents arrive. Whether two figures are comparable, what changed in a company, and whether the change matters to a forecast are questions that deserve human judgment and better analytical tools—not a convenient answer forced by the shape of an API.

The early architects of electronic disclosure might find today's predicament familiar. Their projects transformed financial information, but did not finish the job. Nor should we expect any one standard or library to do so.

The interesting part is how much further the information can travel now, and how much more carefully we can examine it when it gets there.

OpenCorpFilings is an open-source project maintained by SourceState. Explore the repository and current coverage ↗.