Tuesday, October 30, 2018 at 12:31 PM #114394
What do these fields encapsulate?
What sort of values could we expect to see in these fields?
Wednesday, October 31, 2018 at 5:15 PM #114695
report.restated-index is a searchable integer –
/api/v1/report/search?report.restated-index=10&fields=report.*returns a filing that was restated 10 times.
we’re planning to convert report.restated to a boolean (from integer), so you’ll be able to query for the population of restated filings
Friday, November 2, 2018 at 12:03 PM #115012
Thanks for this. Makes sense David.
Can’t remember off the top of my head what markers exist in the SEC XBRL Spec. for restatements? Is there one at a filing level? Is that what is used if indeed it exists to calculate the restatement index or does it just count how many amended versions of the same report have been filed? e.g. 10-K/A. Or do amended filings actually represent unique reports so this is irrelevant? I’m waffling now so I’ll leave it for someone else to hopefully fill in the correct answer!
Tuesday, November 6, 2018 at 6:06 PM #115704
There is no real marker other than the amendment flag, in the filing.
The restatement flag is based on subsequent filings that are an amendment to the original. However, this is a convenience we have added so you know that a filing has been subsequently updated. When looking at data the ultimus index on the fact is the key attribute as this indicates if the fact has been subsequently updated.
A restated filing may not be the complete filing, and can be a portion of the original filing, so ignoring restated filings without an new values in a subsequent filing should probably be avoided.
Wednesday, November 21, 2018 at 10:14 AM #117383
Jasa SEO MurahParticipant
Thanks for the explanation
Wednesday, December 12, 2018 at 2:35 PM #118450
Sorry Campbell needed to go off and do something else. Back on it now.
The fact.ultimus sounds fabulous, a boolean flag to filter in only the most up to date version of a value. I assume it hasn’t quite been implemented yet as its returning the same values as the fact.ultimus-index? And from the values I’ve looked at – examples below – an index of 1 would be the original or first reported value and does an index of 5 mean that, in its reporting life time, it has had five unique values or its just been reported 5 times (been in 5 filings of whatever type)?
“entity.name”: “MICROSOFT CORPORATION”,
“entity.name”: “MICROSOFT CORPORATION”,
Thursday, December 13, 2018 at 7:55 AM #118504
does an index of 5 mean that, in its reporting life time, it has had five unique values or its just been reported 5 times (been in 5 filings of whatever type)?
Having read some other posts, I think I found one of the answers in your third reply, Campbell to this post reports and periods
…Maybe it would be helpful to add a flag to a fact to indicate that it is the latest value reported. This would update like the ultimus but would allow you to get the latest value of assets etc reported. (Wheras ultimus indicates if the same value has been reported subsequently…
Having a pulled back a bunch of values, this appears to be consistent with what I’m seeing.
Thursday, December 13, 2018 at 12:32 PM #118524
Jim – you’re correct:
fact.ultimus-indexis the number of times the fact has been reported, regardless of value, report type, etc. In the index, 1 is the most recent, and the highest reported ultimus integer corresponds to the earliest reporting of the fact.
See Microsoft’s Assets for fiscal year 2015:
fact.ultimusis planned to become boolean.
You must be logged in to reply to this topic.
CIK and Ticker 1 week, 6 days ago
Extracting Data From A Particular Financial Statement 2 weeks, 3 days ago
Missing years 1 month ago
Period details for facts 1 month, 3 weeks ago
Extracting Data From A Particular Financial Statement 1 month, 3 weeks ago
XBRL API Resources
- The XBRL API
- XBRL Data Community
- XBRL API Documentation (PDF)
- Get Data with Google Sheets
- Sample Queries (Insomina REST client) - requires account provision
Using the XBRL API with the Public Filings Database
Unless otherwise agreed to in writing, any and all use of the XBRL API to authenticate and retrieve data from the XBRL US Database of Public Filings implies user consent and agreement with the XBRL US API Agreement. If you are unable to agree to these terms, do not use the XBRL API.
Ready to work with the API in Excel's Power Query, or with your own system or app?
Contact us at email@example.com to have your existing XBRL US Web account provisioned to generate client ID/Secret pairs to work with the XBRL API in a REST client or other application, including Excel's Power Query.
NOTE: You do not need to generate client ID/Secret pairs if you use the Google Add-on and Google Sheet exclusively to access data - the XBRL API Authentication Add-on handles this automatically.
Your account needs to be provisioned before you can login and generate client ID/secret pairs.
Login or register for a free account.
Join XBRL US
- Individual Options - Basic, Power User & Sole Practitioner
- For Your Team - Startup, Non-Profit, Academic & Corporate options
- Member Benefits Comparison Table