The End of Filing Rules

Introduction

My view is that most filing rules shouldn’t exist; not in their current form, at least.

The EDGAR XBRL Guide is 137 pages of PDF. The ESEF reporting manual is 54 pages of PDF. Every country with an XBRL filing programme has a filer manual, sometimes several of them. CoreFiling spends hundreds of developer hours each year updating validation rules encapsulated in these hundreds of pages of PDF, and every XBRL software vendor that operates globally faces a similar Sisyphean task.

Back to Basics

Whenever I see a filing rule expressed in prose, I wonder if there’s a gap in our standards.

Let’s take a few steps back and consider the essence of regulatory reporting.

Someone, call her Reggie, wants reports from someone else, call him Bob. The expected reports and their expected content may vary over time. But, each report is expected by a certain date, and, for each report, Reggie has a pretty clear idea of what she wants to see, even if she gives Bob some discretion about the details and presentation.

With XBRL reporting systems, the “expected content” is largely covered by taxonomies. A dictionary of standardised reporting terms is provided, along with machine-readable documentation of expected dimensional combinations (hypercubes and table templates) and machine-runnable consistency checks (calculations and formula). A great strength of XBRL is that it allows report producers (filers) to iterate locally, checking their work using certified XBRL software, before submitting any data to the report requestor (usually a regulator). This model-driven approach avoids the need for lots of custom code.

• XBRL reports come in many flavours: iXBRL, xBRL-XML, xBRL-JSON and xBRL-CSV. Which of these are allowed?
• How often should a report be submitted?
• What time range should it cover, and what is the appropriate taxonomy to use for a given time range?
• Are extension taxonomies allowed? If so, what sort of extensions are permitted?
• What format should the submission take? A report package, probably, but what’s expected within it?
• Should one or more digital signatures be included?

All of these details and more are considered and documented by each regulator, but not in an optimal form.

Can we do better than PDF?

Fully-Automated Luxury Reporting

If Reggie expects reports from Bob, Reggie should publish a standardised index of structured “reporting requirement” documents at a particular URL.

Reggie should say to Bob:

As a director of a limited company, you are expected to provide certain reports. Please direct your certified XBRL reporting software to <https://reg.gov/ltd>, and provide the reports documented there by the dates they are required.

The structured “reporting requirement” documents should specify everything that regulators care about, directly or indirectly, starting with:

• due date
• submission filename pattern
• submission format

All XBRL submissions should use report packages, so submission format is really about pinning down the allowed versions of the report package specification, and the names and contents of the files within the package.

Imagine a JSON file something like this, which uses globs to express the allowed documents, along with some basic constraints applied to those documents:

{
 “documentInfo”: {
  “documentType”: “https://xbrl.org/2024/reporting-requirement”,
},
“packageType”: “https://xbrl.org/2024/xbrs”,
“reports”: {
  “reports/*.json”: {
    “count”: “1”,
    “filename”: {
     “pattern”: “[a-zA-Z0-9]*.json”
    },
    “content”: {
     “taxonomy”: {
      “packages”: [ “sha256-d3d767461be7f7f20c3170e511aca2de1501b942fce4e9a25d2d0beb413cf6c1” ],
      “includes”: [ “https://xbrl.fasb.org/us-gaap/2024/elts/us-gaap-2024.xsd” ]
      “namespaces”: {
       “count”: “42..43”
      }
     }
     “period”: {
      “range”: “2023-01-01..2024-12-31”,
      “count”: “2..4”,
      “duration”: {
       “allowedValues”: [ “P1Y”, “P9M” ]
      }
     }
     “entity”: {
      “count”: “1”,
      “scheme”: {
       “allowedValues”: [ “http://standards.iso.org/iso/17442” ]
      }
     }
    }
   }
  },
  “supportingDocuments”: {
   “attachments/*.xml”: {
    “count”: “0..”,
    “contentType”: “text/xml”,
    “documentType”: “https://reg.gov/forms/42”
   }
  }
 }

For optional reports, Bob might be expected to submit a short explicit non-disclosure, such as the (i)XBRL equivalent of this statement:

“As a <<limited company>> with <<less than 100 employees>>, we are <<not required to>> submit a <<diversity and inclusion report>>”.

Using knowledge of standing company data, an XBRL report preparation system could prepare non-disclosure reports automatically, and just await human confirmation before submission.

Substantive disclosures would require more interaction from users, but the metadata in the structured “reporting requirement” documents would still help to guide this process.

The submission itself might become more of a publication, especially where there are open data requirements. Instead of providing a custom submission portal and expecting users to periodically POST submissions, regulators could maintain a list of report indexes to check (e.g. ‘https://bob.example.com/.well-known/xbrl-reports’) along with details of who to contact if deadlines are missed, or reports are invalid.

Crazy? Impractical? Inspired?

I feel like there’s merit in the ideas sketched above, and I’m keen to hear from all stakeholders in the reporting process.