Company financials

Overview

Every ITR (quarterly) and DFP (annual) statement CVM publishes, as filed. Two endpoints over the same rows: financials returns the statement lines long, company_financials returns the headline lines wide. financials("PETR4"), financials("33000167000101") and financials("9512") are the same company — a ticker resolves through CVM’s published FCA map, where the trading code and the CNPJ arrive on the same filed row. Nothing is matched by name; a delisted code resolves to nothing rather than to a guess.

Read this before comparing two rows

A quarterly filing publishes the same account twice. Under one ref_date, an ITR carries the three-month figure and the year-to-date figure, and only the period span tells them apart. Every row carries period_months (3, 6, 9, 12 — null on a balance sheet, a point in time). Adding a 3-month row to a 6-month row double-counts the quarter.Nothing is summed, annualised or reconstructed for you: a non-calendar fiscal year and a restated earlier quarter both break naive quarter-subtraction, so the spans are published and the arithmetic is yours.

Three more discriminators, decided for you and visible in the response:

Behaviour	Default	Why
`ordem_exerc`	the period the document is for	A filing prints the prior-year column beside the current one. Returning it would double every series and date last year’s numbers to this year’s `ref_date`.
`scope`	`con` (consolidated)	Consolidated and individual are separate filings of the same period. Pass `p_scope: "ind"`; they are never merged.
`version`	newest only	A restatement re-files under a higher version and the originals remain. Only the newest is served; `version` carries which.

`financials` — statement lines, long

curl -s -X POST "$SILO_URL/rpc/financials" \
  -H "apikey: $SILO_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"p_id":"PETR4","p_statement":"DRE"}'

Argument	Default	Meaning
`p_id`	—	ticker, CNPJ (14 digits) or CVM code
`p_statement`	every statement	`DRE` income · `BPA` assets · `BPP` liabilities + equity · `DFC_MD` / `DFC_MI` cash flow · `DMPL` changes in equity · `DRA` comprehensive income · `DVA` value added
`p_from` / `p_to`	last 5 years	window on `ref_date`
`p_scope`	`con`	`con` or `ind`
`p_doc_type`	both	`itr` (quarterly) or `dfp` (annual)
`p_as_of`	`null`	a date T makes the read point-in-time: only documents CVM received before T (see Point in time)

One row per account line:

[
  { "id": "9512", "id_type": "cd_cvm", "ticker": "PETR4",
    "company": "PETROLEO BRASILEIRO S.A. PETROBRAS",
    "doc_type": "itr", "statement": "DRE", "scope": "con",
    "ref_date": "2025-06-30", "period_start": "2025-04-01",
    "period_end": "2025-06-30", "period_months": 3,
    "account_code": "3.01", "account_name": "Receita de Venda",
    "value": 120000000000.00, "version": 1, "source": "cvm" }
]

value is absolute BRL — the publication scale is applied at ingest, so no caller has to know it.

`company_financials` — headline lines, wide

One row per (document, reference date, period span), for when you want the shape rather than the ledger.

curl -s -X POST "$SILO_URL/rpc/company_financials" \
  -H "apikey: $SILO_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"p_id":"PETR4"}'

rows = requests.post(f"{URL}/rpc/company_financials",
                     headers=H, json={"p_id": "PETR4"}).json()

const { data } = await supabase.rpc('company_financials', { p_id: 'PETR4' })

Carries revenue, gross_profit, net_income, total_assets, equity, net_margin_pct and roe_pct beside the same period_months, scope and version columns.

roe_pct is the period’s return on equity and is not annualised — a three-month row divides one quarter’s profit by equity. period_months says which span you have.
Where a company re-filed only its balance sheet, total_assets and equity read null rather than being paired with an income statement from a different version.

Banks file a different chart of accounts, but net income still lands on 3.11. For Banco do Brasil (cd_cvm 1023, FY2024 consolidated) 3.11 is Lucro ou Prejuízo Líquido Consolidado do Período, exactly as for an industrial filer.What differs is the meaning of the other codes — 3.01 is interest income rather than sales, 3.05 is pre-tax profit rather than EBIT — so read the account_name beside a code rather than assuming it carries the same concept across charts. That is also why setor and segmento ride on every row: partition a peer comparison by sector rather than ranking revenue across charts.net_income is resolved from the filed label (catalog v36), the same way as api.income_statements: 3.11 for most filers, 3.09 for the one bank chart that files no 3.11, 3.13 for insurers. No code is substituted for another — 3.09 is profit before the statutory profit-sharing on 3.10 on every other chart.

Note: one 1,000-row page, and it refuses above it (22023). There is no cursor — narrow the window, pin a p_statement, or ask for one p_doc_type.

Point in time

By default every document is read at its latest stored version, so a filing that arrived later, or a restatement, shows as if it had been known on an earlier date. That is right for a current screen and look-ahead in a backtest. financials, company_financials, income_statements, balance_sheets and cash_flow_statements all take a trailing p_as_of date that removes it:

curl -s -X POST "$SILO_URL/rpc/financials" \
  -H "apikey: $SILO_ANON_KEY" -H "Content-Type: application/json" \
  -d '{"p_id":"PETR4","p_statement":"DRE","p_as_of":"2024-02-29"}'

Only documents CVM had received before the date are read. One received on the date itself is out. ref_date still says which period a row is for, and the window p_from / p_to is on that, not on the receipt date.
Of each document the highest remaining version is kept, with all its lines. A document with no filing header is dropped, never assumed early.
PETR4’s 2023 annual statements were received on 2024-03-08, so at 2024-02-29 the newest period is the quarter ended 2023-09-30.
CVM’s files carry only the newest version of each document, and versions superseded before 2026 are mostly not held. An as-of read is therefore stale for a company that restated, never early: a restating company looks later than it was.
financial_statement_history already lists every stored version with its filing_received_date.

Freshness

coverage carries a financials row whose as_of is the newest reference date any filing has reached. Its complete_through is deliberately null: the completeness model describes fund filing cadence and says nothing about companies, and a fabricated completeness date is the claim coverage exists to prevent.

Not served here

panel has no company arm yet. The panel is one value per (id, date, metric), and a quarterly filing offers two spans under one date; picking one silently is the kind of wrong number this API refuses to make. Use these endpoints for fundamentals and panel for prices until the span is settled in the contract.
Per-share figures. Share counts are a separate filing; nothing here divides by a number it did not read.

Overview

Data

Get started

Guides

API reference

Endpoints

Company financials

Overview

Read this before comparing two rows

`financials` — statement lines, long

`company_financials` — headline lines, wide

Point in time

Freshness

Not served here

​Overview

​Read this before comparing two rows

​financials — statement lines, long

​company_financials — headline lines, wide

​Point in time

​Freshness

​Not served here

Overview

Read this before comparing two rows

`financials` — statement lines, long

`company_financials` — headline lines, wide

Point in time

Freshness

Not served here