An earnings date is useful, but it does not answer every question an analyst has when planning for a reporting week. Teams also need to know which fiscal period the company is reporting, whether the date is confirmed or estimated, and when the announcement is expected relative to market hours. Without that context, a calendar still leaves part of the scheduling and period-matching work to the user.
The FMP Earnings Calendar now supports an includeReportTimes query parameter that adds this context to the response. When the parameter is set to true, users receive additional information about the period of report, confirmation status, and estimated report time. The update is documented in the FMP developer changelog and is available through the existing Earnings Calendar API.
This is a relatively focused product update, but it addresses several familiar problems in earnings-season workflows. It gives analysts a clearer connection between an event and the financial period it covers, while also helping research teams organize their work around the expected reporting window. Developers can use the same context when deciding when to refresh watchlists, models, dashboards, and downstream datasets.
Key Takeaways
- Setting includeReportTimes=true adds reporting-period, confirmation-status, and estimated report-time context to the Earnings Calendar response.
- Reporting-period information helps connect an announcement with the fiscal quarter or year it covers.
- Confirmation status helps teams distinguish firmer reporting dates from dates that may still change.
- Estimated report timing can support separate workflows for before-market and after-market announcements.
- The added information supports scheduling and data alignment, but it does not predict the result or guarantee the exact time of release.
What the Updated Earnings Calendar Parameter Adds
The standard Earnings Calendar provides a date-based view of upcoming and historical earnings events, including estimated and actual EPS where available. The optional includeReportTimes parameter expands that view with more information about the report behind each calendar entry. Users can request the additional context through the same stable endpoint:
|
https://financialmodelingprep.com/stable/earnings-calendar?includeReportTimes=true&apikey=YOUR_API_KEY |
The additional information falls into three practical categories:
|
Added Context |
What It Describes |
How It Can Be Used |
|
Period of report |
The fiscal period associated with the earnings event |
Match the event with the correct quarter or fiscal year in a model |
|
Confirmation status |
Whether the calendar entry is marked as confirmed or estimated |
Prioritize confirmed dates while continuing to monitor estimates |
|
Estimated report time |
The expected reporting window relative to market hours |
Organize preparation and refresh work around morning or evening releases |
These details are most useful when the response is treated as an operational schedule rather than a prediction about company performance. The period information helps organize financial data, while confirmation and timing information help organize the work surrounding the event. Each serves a different purpose and should remain a separate field in the downstream workflow.
Connect the Announcement Date to the Fiscal Period Being Reported
The date of an earnings announcement and the end date of the reporting period describe different points in the financial calendar. A company may announce results in February for a quarter that ended in December, while another company reports a January-ending fiscal quarter several weeks later. Comparing those events only by announcement date can obscure which operating periods are actually being discussed.
Reporting-period context helps analysts connect each calendar event to the appropriate financial statement and estimate period. This is particularly useful for companies whose fiscal calendars do not follow standard calendar quarters, including many retailers and technology companies. A calendar entry can then be matched to the correct revenue, EPS, guidance, and model period without relying on a generalized calendar-quarter assumption.
That alignment becomes important when comparing reported results with consensus estimates. A third-quarter actual should be compared with a third-quarter estimate that follows the same fiscal-year convention. If the periods are mismatched, the resulting earnings surprise or growth calculation may be mathematically correct but economically meaningless.
The new context does not replace validation of the underlying financial data. Analysts should still confirm that the fiscal year, fiscal quarter, and company reporting convention match across the calendar, estimate, and statement datasets. The update makes that validation easier by providing more of the relevant period information earlier in the workflow.
Treat Confirmed and Estimated Dates Differently
Earnings calendars often include estimated dates before a company formally establishes its reporting schedule. Those estimates are valuable because they give analysts an early view of the likely earnings-season workload, although the dates may change. A confirmation indicator makes it easier to distinguish preliminary calendar entries from events with firmer scheduling information.
Research teams can use estimated dates for advance planning and confirmed dates for more specific assignments. An estimated event might prompt an analyst to review the model, check the latest consensus figures, and reserve time during the expected week. Once the date is marked as confirmed, the team can finalize coverage responsibilities and set a more precise refresh schedule.
Estimated events should not automatically be removed from a watchlist because doing so would reduce visibility before confirmation arrives. A more practical approach is to retain both statuses, display them clearly, and refresh the calendar regularly. This gives the team advance notice without treating an estimated date as fixed.
Confirmation status should also remain separate from any interpretation of the company's outlook. A date being confirmed, estimated, delayed, or revised does not by itself indicate whether the company will beat or miss expectations. The field describes the scheduling status of the event, not the quality of the forthcoming results.
Use Estimated Report Time to Organize the Day
The expected reporting window affects how an analyst prepares for an earnings event. A company expected to report before the market opens may require model and briefing preparation to be completed the previous afternoon. A company expected to report after the close gives the team more time during the trading day but may shift the post-report work into the evening.
Grouping events by expected report time can make a crowded earnings day easier to manage. Analysts can separate morning releases from evening releases, identify overlapping events, and decide which models or dashboards need to be ready first. Data teams can use the same distinction when planning refresh jobs and monitoring for new results.
The timing field should still be treated as an estimate rather than an exact publication timestamp. Companies can release results earlier or later than expected, and some calendar entries may not include a usable timing value. Workflows should accommodate missing or changing timing information instead of assuming that every report will arrive within a fixed window.
For automated systems, the expected window can guide when monitoring begins without becoming the sole trigger for a data refresh. A pipeline might start checking more frequently around the anticipated release window and continue until the updated results appear. This approach uses the calendar as a scheduling aid while allowing the actual data arrival to determine when downstream processing begins.
Build the Calendar Into a Broader Earnings Workflow
The Earnings Calendar establishes when a report is expected and which period it covers, but it is only the first stage of the research process. Before the event, the emphasis is on scheduling, period alignment, and preparation. After the report, attention shifts to the reported figures, the difference from expectations, management commentary, and the market response.
A practical workflow can be organized as follows:
|
Stage |
Information Used |
Analyst or Data-Team Action |
|
Early planning |
Estimated date and reporting period |
Add the event to the watchlist and identify the model period that will need updating |
|
Final preparation |
Confirmation status and expected report time |
Assign coverage, review estimates, and prepare the relevant model or spreadsheet |
|
Results processing |
Reported EPS, revenue, and other financial results |
Update actuals and compare the release with prior expectations |
|
Surprise analysis |
Actual and estimated earnings data |
Measure the size and direction of the earnings difference |
|
Qualitative review |
Earnings-call transcript and management commentary |
Evaluate guidance, operating explanations, and changes in management tone |
|
Follow-up |
Price reaction and revised estimates |
Assess how the market and analysts responded to the new information |
Once the results are available, the Earnings Surprises Bulk API can support broader analysis of reported earnings relative to estimates. That dataset belongs to the post-report stage rather than the calendar-planning stage. Keeping the two roles distinct helps prevent expected events and completed results from being mixed in the same workflow.
Management commentary adds another layer that cannot be captured by the calendar or surprise calculation alone. The Search Earnings Transcripts API can help researchers locate the relevant call once the report has taken place. Analysts can then examine guidance, segment commentary, cost pressures, demand conditions, and other explanations behind the reported numbers.
Practical Controls for Using the New Context
The added calendar information can improve an earnings workflow when each field is interpreted according to its purpose. Reporting period belongs to the data-alignment layer, while confirmation and report time belong primarily to the scheduling layer. Keeping those functions separate makes it easier to understand why each value is present and how frequently it may need to be refreshed.
Teams incorporating the new parameter should consider the following controls:
- Store the earnings announcement date separately from the fiscal period being reported.
- Retain both confirmed and estimated events rather than filtering estimates out of the calendar.
- Refresh estimated events regularly because their dates or timing may change.
- Treat report time as an expected window rather than a guaranteed release timestamp.
- Preserve missing values instead of replacing them with assumed morning or evening classifications.
- Match fiscal quarter and fiscal year across calendar, estimate, and financial-statement data.
- Trigger final post-report processing from the arrival of actual results rather than the expected time alone.
- Keep scheduling metadata separate from signals about earnings quality or likely market performance.
These controls are straightforward, but they prevent useful scheduling context from being given more analytical meaning than it carries. The update helps teams prepare for an event and connect it to the correct reporting period. The interpretation of the results still depends on the financial data and research performed after the company reports.
A More Informative Starting Point for Earnings Research
The addition of reporting-period, confirmation-status, and estimated timing context makes the Earnings Calendar more useful for analysts who manage several upcoming reports at once. It provides a better view of what each event covers and how firmly it belongs on the schedule. That added clarity can improve watchlist organization, model preparation, and the handoff from calendar monitoring to post-report analysis.
The calendar should still be treated as the starting point of the workflow rather than a substitute for the underlying research. Estimates and timing information can change, and the actual release determines when new fundamentals become available. Used with those limitations in mind, the updated response gives analysts and data teams a more complete basis for planning earnings-season work.
Frequently Asked Questions
What does the includeReportTimes parameter do?
Setting includeReportTimes=true adds reporting-period, confirmation-status, and estimated report-time context to the Earnings Calendar response. These additions help users connect an event to the period it covers and organize work around its expected schedule.
Why is the reporting period different from the earnings date?
The reporting period identifies the fiscal quarter or year covered by the results, while the earnings date identifies when the company is expected to announce them. Since corporate fiscal calendars do not always follow calendar quarters, both pieces of information are needed to align reports, estimates, and models correctly.
What is the difference between a confirmed and estimated earnings date?
A confirmed date is marked with firmer scheduling status, while an estimated date may still change as the reporting event approaches. Both can remain in the watchlist, but teams may use confirmed dates for more specific assignments and refresh schedules.
Does the estimated report time provide an exact release timestamp?
The report-time context describes an expected reporting window rather than guaranteeing an exact publication time. Workflows should allow for delays, changes, and missing timing values.
Does a change in confirmation status indicate anything about the expected results?
Confirmation status describes the scheduling status of the earnings event and does not indicate whether the company is likely to beat or miss expectations. Any interpretation of earnings quality should come from the reported financial results, guidance, estimates, and related analysis.
