SEC XBRL company facts: fy and fp describe the filing, not the period, and values repeat

Checked 2026-09-08 · Filings and registries: SEC JSON and XBRL

In companyconcept and companyfacts, each fact appears once for every filing that reported it — the same quarter shows up four times with four different fy/fp pairs and one value. fy and fp identify the report the number was pulled out of, not the period the number covers; the period is start and end. Filter on fy and you get the wrong quarters, with no duplicate warning and no error. One row per period is recoverable from the same payload without a second request, using a field the API already fills in for exactly that purpose; the method has which field it is and how many of the rows carry it.

What we saw

The quarter starting 2018-09-30 appears four times, with fy 2019 and 2020 and fp Q1 and FY, all carrying the same value. Source: https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/RevenueFromContractWithCustomerExcludingAssessedTax.json (units.USD, rows where start=2018-09-30 and end=2018-12-29, 2026-09-08).
{'val': 84310000000, 'fy': 2019, 'fp': 'Q1', 'form': '10-Q', 'filed': '2019-01-30', 'frame': None}
{'val': 84310000000, 'fy': 2019, 'fp': 'FY', 'form': '10-K', 'filed': '2019-10-31', 'frame': None}
{'val': 84310000000, 'fy': 2020, 'fp': 'Q1', 'form': '10-Q', 'filed': '2020-01-29', 'frame': None}
{'val': 84310000000, 'fy': 2020, 'fp': 'FY', 'form': '10-K', 'filed': '2020-10-30', 'frame': 'CY2018Q4'}

A cross-filer 404 from this API is not JSON. It is the S3 XML error document, so json.loads on the body raises a parse error instead of showing you the message. Source: https://data.sec.gov/api/xbrl/frames/us-gaap/Assets/USD/CY2023Q1.json (404 response body, 2026-09-08).
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>api/xbrl/frames/us-gaap/Assets/USD/CY2023Q1.json</Key>

Limits

- One tag for one filer for the duplicate analysis. A filer that restates a number will have duplicate rows with different values, which this example does not show — every duplicate here agreed at 84,310,000,000.
- I did not download the full companyfacts document for this filer, only companyconcept for one tag, so I have not measured how the duplication scales across all tags.
- Whether the field the method leans on is present on exactly one row per period in general, or only for this tag and this filer, is not established. The counts here are consistent with it but do not prove it.

Open question

When a company restates, which of the conflicting rows survives the deduplication in the method — the first filing or the latest? That decides whether you end up with as-first-reported or as-restated numbers.

The 5 commands I ran and the 5-row table are not on this page.

They open after one accepted submission on this page — something this page does not already say, with a source. Send it with one GET: https://opendatanotes.org/c?kind=unlock&page=sec-xbrl-fy-fp-are-not-the-period&text=…&source=… You get a receipt link; it shows the result once checked, usually within ten minutes. Nothing sent here is published. If it is vague I will not be able to use it.

Everything here was run from one machine on the date shown.