Financial Events Guide财报事件指南

Free Earnings Calendar API
for Reliable Event Data
获取可靠财报事件数据的
免费财报日历 API

Choose an earnings calendar by confirmed event times, estimate coverage, revisions, history, and usage rights—not by symbol count alone.

选择财报日历时,应重点核查已确认的财报时间、分析师预估覆盖范围、数据修订、历史记录与使用授权,不能只看可查询的股票代码数量。

Hand-drawn free earnings calendar API workflow showing date and symbol queries, normalization, estimates, market timing, revisions, and application uses

TL;DR核心摘要

An earnings calendar API is a changing schedule of expected corporate events, not a permanent list of dates. A production record should show who is reporting, which fiscal period the event covers, whether the date and session are estimated or confirmed, when the schedule last changed, and what source supports it. The API is most useful for planning alerts, workload, and portfolio monitoring before results are released.

财报日历 API 提供的是持续变化的公司事件安排,而不是一份永远不变的日期清单。生产记录应说明由哪家公司发布、对应哪个财务报告期、日期和发布时段属于预计还是确认状态、日程何时发生过变化,以及依据什么来源。它最适合在业绩公布前安排提醒、计算任务和持仓监控。

A date is not enough

Keep the exchange timezone, before-market or after-market flag, confirmation status, and last-updated timestamp with every event.

Estimates change

EPS and revenue consensus can change until release. Snapshot estimates when alerts, event studies, or backtests depend on earlier information.

只有日期远远不够

每条财报事件都应保留交易所所在时区、盘前或盘后标识、确认状态以及最后更新时间。

一致预期会持续变化

每股收益与营收的一致预期在财报发布前都可能发生变化。如果提醒、事件研究或回测需要以当时可获得的信息为依据,就必须保存各时点的预期数据快照。

Fields a useful earnings calendar API should return实用的财报日历 API 应返回哪些字段

At minimum, expect a stable company identifier, ticker, exchange, event date, event time or session, fiscal quarter, fiscal year, currency, confirmation status, and updated timestamp. A date without timezone semantics is unsafe: midnight UTC can become the prior local date, while “after market close” describes a session rather than an exact clock time.

至少应返回稳定的公司标识、股票代码、交易所、事件日期、财报时间或发布时段、财务季度、财年、币种、确认状态与更新时间。缺少时区语义的日期并不可靠:UTC 零点可能对应当地前一日,而“盘后发布”表示市场时段,并非精确的时刻。

For analysis, look for estimated and actual EPS, estimated and actual revenue, the number of contributing analysts, surprise values, and source provenance. Keep raw and normalized values separately. Providers may define adjusted EPS, diluted EPS, consensus, and surprise percentages differently, so field names alone do not guarantee comparable numbers.

用于分析时,还应关注每股收益预估值与实际值、营收预估值与实际值、参与预估的分析师数量、实际值相对预估值的偏离幅度以及数据来源。原始值与标准化值必须分开保存。不同服务商对调整后每股收益、摊薄每股收益、一致预期和实际值偏离预期的百分比可能采用不同定义,字段同名并不代表数值可以直接比较。

Field group字段组What to retain需要保留的内容Why it matters重要性
Identity主体标识Provider ID, ticker, exchange, company name服务商 ID、股票代码、交易所、公司名称Tickers change and can be reused.股票代码可能变更或被重新使用。
Timing时间信息Date, timezone, session, confirmation, updated time日期、时区、财报发布时段、确认状态、更新时间Prevents late or misdated alerts.避免提醒延迟或日期归属错误。
Event status事件状态Estimated, confirmed, rescheduled, postponed, cancelled, reported预计、确认、改期、延期、取消和已发布Lets applications update or withdraw scheduled work safely.便于应用安全地更新或撤销已安排任务。
Fiscal context财务期间Fiscal year, quarter, period end, report type财年、财季、报告期末和报告类型Prevents a calendar event from being assigned to the wrong quarter.防止把财报事件关联到错误季度。
Results财报结果EPS and revenue estimates, actuals, currency, units每股收益与营收的预估值、实际值、币种和单位Supports consistent surprise calculations.便于按一致口径计算实际值与预估值的差异。
Change history变更历史Prior dates, sessions, statuses, source, and observation times此前日期、发布时段、状态、来源和观察时间Supports audit, schedule-quality analysis, and point-in-time research.支持审计、日程质量分析和历史时点研究。

How to test coverage, timing, and revisions如何验证覆盖范围、数据时效与修订情况

Test more than large US companies. Query ADRs, newly listed issuers, firms with non-calendar fiscal years, multiple share classes, and symbols that changed. Compare upcoming events with company investor-relations pages or exchange notices, then compare reported values with filings. Record whether an event is estimated, confirmed, postponed, cancelled, or reported.

测试范围不能只包含美国大型公司。还应查询美国存托凭证(ADR)、新上市公司、财年不按自然年计算的公司、设有多个股份类别的公司,以及更换过股票代码的公司。将即将发生的财报事件与公司投资者关系页面或交易所公告对照,再用监管申报文件核验已披露的实际值。同时记录事件是暂定、已确认、延期、取消,还是已公布结果。

Measure freshness through changes, not a marketing label. Poll a representative week and log when dates, sessions, estimates, and actuals first appear and when they change. A provider can update quickly after release yet still publish an unreliable schedule days earlier. Historical endpoints should also preserve the estimate visible before the announcement rather than attaching today’s consensus to an old event.

衡量数据时效时,应跟踪数据的实际变化,而不能只看宣传用语。选取具有代表性的一周持续轮询,记录财报日期、发布时段、预估值与实际值首次出现以及后续发生变化的时间。服务商即使能在财报公布后迅速更新实际值,此前多日给出的财报日程仍可能不可靠。历史接口还应保留财报发布前当时可见的预估值,不应把当前的市场一致预期回填到过往事件。

Create a stable event key

Combine legal company identity, fiscal period, event type, and provider event ID. Do not key only by date: the date may change, and one issuer may schedule several events on the same day.

Store schedule observations instead of overwriting

Append each observed date, session, status, source, and observation time. A current view can show the latest confirmed schedule, while the history explains how often and how late the provider changed it.

Normalize sessions with exchange calendars

Interpret BMO, AMC, and during-market labels in the listing exchange timezone. Use the exchange trading calendar for holidays, half days, and daylight-saving transitions rather than applying one global clock rule.

Design idempotent alerts

Schedule, update, postpone, cancel, and complete alerts using the stable event key. Repeated polls should not create duplicate notifications, while material schedule changes should update the existing event visibly.

Separate calendar ingestion from results ingestion

The calendar service plans work before publication; a reported-results service confirms actual values afterward. Keep their polling frequencies, completion rules, latency metrics, and error states separate.

Measure schedule reliability as an SLA

Across several reporting cycles, measure company coverage, first-seen lead time, confirmation lead time, reschedule detection delay, cancellation accuracy, and duplicate-event rate. Segment results by market capitalization, exchange, and region. A calendar that looks complete on announcement day may still be unsuitable if it discovers smaller issuers too late for research preparation.

建立稳定的事件主键

结合公司法律主体、财务报告期、事件类型和供应商事件 ID 建立主键。不能只按日期识别事件,因为日期可能变更,同一发行人也可能在一天安排多个活动。

追加日程观察记录,而不是覆盖旧值

每次观察到的日期、发布时段、状态、来源和观察时间都应追加保存。当前视图可以展示最新确认安排,历史记录则用于解释供应商多久会改期、通常提前多久确认。

结合交易所日历统一发布时段

BMO、AMC 和盘中发布等标签应按上市交易所时区解释。节假日、半日交易和夏令时变化应使用交易所交易日历,不能套用一个全球统一时钟规则。

设计具备幂等性的提醒

基于稳定事件主键安排、更新、延期、取消和完成提醒。重复轮询不能产生重复通知,而重大日程变化应清楚更新原有事件。

分开处理日历数据与实际业绩

日历服务用于业绩公布前安排任务,实际业绩服务用于发布后确认数值。两者的轮询频率、完成条件、延迟指标和错误状态应分别设计。

把日程可靠性作为 SLA 衡量

跨多个财报周期统计公司覆盖率、首次发现提前量、确认提前量、改期发现延迟、取消准确率和重复事件率,并按市值、交易所和地区拆分结果。某个日历即使在公告当天看起来很完整,如果对中小公司发现得太晚,仍不适合用于提前安排研究任务。

Build an earnings-event workflow that survives schedule changes构建能够应对财报改期的事件工作流程

An earnings calendar becomes operationally useful only when the application reacts differently to discovery, confirmation, rescheduling, publication, and completion. Treat the calendar as a versioned event stream. Each observation should update the same stable event record, while every material change remains available for audit and point-in-time analysis.

只有当应用能够针对首次发现、正式确认、日程变更、业绩发布和事件完成采取不同动作时,财报日历才真正具备生产价值。应把日历视为带版本的事件流:每次观察都更新同一个稳定事件记录,同时保留所有重大变化,以便审计和历史时点分析。

1. Discover and prepare

When an estimated date first appears, create a provisional event and schedule low-frequency checks. Attach the issuer, fiscal period, expected session, source, and first-seen time. Research preparation can begin, but user-facing copy should still label the date as unconfirmed.

2. Confirm and tighten monitoring

When the issuer or provider confirms the date, preserve the prior estimate, mark the confirmation source and time, and increase polling as the release window approaches. If the session changes from before-market to after-market, update the existing alert instead of creating a second event.

3. Ingest the release once

After publication, acquire actual EPS and revenue through a separate results workflow. Use an idempotency key so repeated provider responses cannot send duplicate alerts. Partial releases should remain open until required fields arrive or a documented timeout policy closes the event.

4. Complete with evidence

Store the actual-value source, source timestamp, retrieval time, estimate snapshot used for comparison, units, currency, and any later corrections. Completion should mean the required evidence is present—not merely that the expected clock time has passed.

1. 首次发现并开始准备

当预计日期首次出现时,创建暂定事件并安排低频检查,同时记录发行人、财务报告期、预计发布时段、来源和首次发现时间。此时可以开始研究准备,但面向用户的内容仍应明确标注“尚未确认”。

2. 确认日期并加强监控

当公司或数据服务商确认日期后,保留此前的预计值,记录确认来源与时间,并在发布窗口临近时提高轮询频率。如果发布时段由盘前改为盘后,应更新原提醒,而不是再创建一个重复事件。

3. 业绩发布后只处理一次

业绩公布后,通过独立的实际业绩流程获取 EPS 与营收,并使用幂等键避免供应商重复返回数据时多次发送提醒。若披露内容不完整,应保持事件未完成状态,直到必需字段到齐,或按明确的超时规则关闭。

4. 用完整证据结束事件

保存实际值来源、来源时间、抓取时间、用于比较的预期快照、单位、币种以及后续更正。所谓“完成”,应代表必需证据已经齐全,而不是预计发布时间已经过去。

Worked surprise example. Assume the last pre-release snapshot contains EPS consensus of $1.10 and revenue consensus of $2.42 billion. The company reports EPS of $1.24 and revenue of $2.48 billion. EPS surprise is ($1.24 − $1.10) ÷ |$1.10| = 12.7%; revenue surprise is ($2.48bn − $2.42bn) ÷ $2.42bn = 2.5%. Store the raw differences as well as the percentages, together with the estimate timestamp, analyst count, currency, unit scale, and whether the figures are GAAP or adjusted. When the consensus is zero or negative, percentage surprise can be unstable or counterintuitive, so the raw difference and calculation method should remain visible.

实际值偏离预期的计算示例。 假设财报发布前最后一份快照中的 EPS 一致预期为 1.10 美元、营收一致预期为 24.2 亿美元;公司实际公布 EPS 1.24 美元、营收 24.8 亿美元。EPS 相对预期高出 (1.24 − 1.10) ÷ |1.10| = 12.7%,营收相对预期高出 (24.8 − 24.2) ÷ 24.2 = 2.5%。除了百分比,还应保存原始差值、预期快照时间、分析师数量、币种、单位以及数据属于 GAAP 还是调整后口径。当一致预期为零或负数时,百分比可能失真或不符合直觉,因此必须同时展示原始差值和计算方法。

Use QVeris to find earnings calendar capabilities使用 QVeris 查找财报日历功能

QVeris helps AI agents discover, inspect, and call earnings-calendar and corporate-event tools. An agent can compare date-range inputs, company identifiers, event states, timezone semantics, fields, and limits before routing a request. QVeris simplifies access; the application still owns event identity, schedule versioning, exchange-calendar logic, alert idempotency, and source verification.

QVeris 帮助 AI 智能体发现、检查并调用财报日历和公司事件工具。智能体可以比较日期范围参数、公司标识、事件状态、时区语义、返回字段和调用限制,再把请求交给合适的服务。QVeris 能够简化访问,但事件身份、日程版本、交易所日历逻辑、提醒幂等性和来源核验仍由应用方负责。

FAQ常见问题

Is there a completely free earnings calendar API?

Some providers offer public endpoints or a free plan, but quotas, history, exchange coverage, delayed fields, and commercial rights vary. Verify the current terms before production use.

What does BMO or AMC mean?

BMO means before market open and AMC means after market close. They are session labels, not precise timestamps, and should be interpreted in the relevant exchange timezone.

Can I backtest earnings events with a free API?

Only if the data preserves the schedule and consensus known at each historical point. Latest-only records create look-ahead bias.

How often should an earnings calendar refresh?

Refresh distant events less often and increase frequency as the expected date approaches. Confirmed events and active earnings-season watchlists deserve tighter polling than unconfirmed dates months away.

What should happen when a company changes the date?

Append the new schedule observation, retain the prior value, update existing alerts, and explain the changed status. Do not delete and recreate the event under a new identity.

Can one company have several earnings events?

Yes. Results releases, conference calls, guidance calls, and investor events can share a date. Use event type and stable event ID rather than assuming one row per company per day.

Should estimates be part of the calendar record?

They can enrich the event, but store versioned estimates separately and reference the selected snapshot. A changing consensus should not silently mutate a scheduling record.

是否存在完全免费的财报日历 API?

部分服务商提供公共接口或免费套餐,但请求配额、历史数据范围、交易所覆盖、部分字段是否延迟提供以及商业使用权各不相同。用于生产环境前必须核查最新条款。

BMO 和 AMC 分别表示什么?

BMO 表示财报在开盘前发布,AMC 表示财报在收盘后发布。两者都是交易时段标签,并非精确时间戳,应按相关交易所所在时区理解。

免费 API 能用于财报事件回测吗?

可以,但数据必须保留各历史时点可知的财报日程和分析师一致预期。只保存最新状态的数据会造成前视偏差。

财报日历应该多久刷新一次?

距离预计日期较远的事件可以降低刷新频率,临近发布时再逐步提高。已确认事件和财报季重点自选股,应比数月后的未确认日期轮询得更频繁。

公司更改财报日期时应该怎么办?

应追加新的日程观察记录,保留原值,更新已有提醒,并说明状态变化。不能删除旧事件后以新身份重新创建。

一家公司可能同时有多个财报相关事件吗?

可能。业绩公告、财报电话会、业绩指引说明会和投资者活动可能在同一天举行。应使用事件类型和稳定事件 ID,而不是假定每家公司每天只有一条记录。

一致预期应该直接放在日历记录中吗?

可以用于补充事件信息,但带版本的预期数据应单独保存,并在日历中引用所选快照。持续变化的一致预期不能静默改写日程记录。

References and next steps参考资料与后续步骤