Cash distributions and dividend yield

The only source outside CVM — and why

Everything else in this database comes from CVM open data (DFP, ITR, registry). Cash distributions are the exception: CVM does not publish a CSV of cash distributions comparable to the financial statements. The source here is B3 itself, through the public service GetListedCashDividends, which returns the history of dividends and JCP (interest on equity, a Brazilian dividend-like payout) per company.

The link between our cd_cvm and the filter B3 understands (tradingName) is the codeCVM from B3's catalog (GetInitialCompanies) — matched by equality codeCVM == cd_cvm, never by name similarity. Current coverage: 300 of the 304 companies with a resolved ticker (98.7%). The few left out are the ones that do not appear in B3's catalog — the limitation is declared, not hidden.

What is stored

Each cash distribution is recorded as B3 delivers it, with the original type preserved for auditing:

data_com vs ex-date. B3 reports the last day with the right (lastDatePriorEx). The ex-date — the first trading session in which the share already trades without the distribution — is the following session. We do not derive it here because that would require a trading calendar; we store the raw datum and leave the rule explicit.

Dividend yield (12 months)

• 12m DY = sum of distributions with data_com in the last 365 days ÷ last available closing price (COTAHIST of the main ticker).
• The annual summary and the DY consider only the class of the ticker being queried (ON/PN/UNT, inferred from the code's ending: 3→ON, 4→PN, 11→UNT). Adding up distributions of ON and PN would mix different shares. The proventos block of the response carries all classes, raw.
• It is a historical yield (what was paid), not a projection. Gross value: on JCP there is a 15% withholding tax at source that is not deducted here.

The ex-date before it happens: the filing to the regulator

B3 only publishes a stock dividend after the ex-date — a sweep of the whole universe (356 issuers) on 2026-09-11 found no future ex-date at all. So the stock calendar reads a second source: the "Relatório Proventos" (dividend report) a company files with CVM when it declares a dividend (its own IPE category, listed in the open dataset ipe_cia_aberta_{year}.zip). The form carries the approval date, the last trading day with rights (the ex-date), ISIN, gross amount per share, period and payment date. Measured on 2026-09-11 over the 58 most recent filings: it arrives a median of 2 days before the ex-date (40 of 58 before it; 12 to 84 days for Banco do Brasil, Vibra, Embraer, Caixa Seguridade); the late ones are re-filings of dividends already paid.

What this source does not say: whether it is a dividend or interest on equity. The row enters as PROVENTO and the pages say so — we do not invent the type. When B3 publishes the same dividend (same company, share class, ex-date and amount), the B3 row, with its type, is the one that counts for history and yield; the filing only covers what B3 has not yet published. Every calendar item from this source links to the document at CVM. Free-format filings (some companies attach their own letter) are recorded as sem_parse, with the link, without guessing fields. Tables provento_cvm and provento_cvm_doc; read every night, along with the price.

Declared limitations

• Source B3, not CVM: subject to changes in the public service. Ingestion is best-effort — if B3 is unavailable during the build, the existing history is kept and the pipeline goes on (the distribution invariants turn to skip instead of failing).
• Only cash distributions (dividends, JCP, income distributions). Stock bonuses and splits are not part of this block.
• History per company is paginated in blocks of 120 (the ceiling of B3's service), walked to the end — without silent truncation.
• Historical preco_com is not adjusted for splits at the source. When the distribution per share exceeds 5× the price reported on the data-com (a clear sign of an unadjusted price in old data), the record gets the flag preco_com_nao_ajustado: the distribution amount remains reliable, but the preco_com of that record does not. The flag is born together with the number, as everywhere in this database.