Best Bitcoin API for Corporate Treasury Teams and Auditors

If your company holds bitcoin on its balance sheet, the quarter-end close now has a line in it that did not exist a few years ago. Under ASU 2023-08, in-scope crypto assets are measured at fair value at every reporting date, with the change running through net income. Fair value is price times units. Finance teams spend a lot of energy on the price half. This guide is about the units half, because that is where the data vendor decision gets made, and where most public APIs quietly fall short.

We are a Bitcoin data provider, so weigh that. Every number below was measured directly and is dated, and where a free tool does the job we say so.

What does a corporate treasury team need from a Bitcoin API?

Four things, in order of how often they go wrong. First, a balance for each wallet as of the reporting cutoff, to the satoshi, reproducible months later when the auditor asks. Second, every transaction in and out of those wallets during the period, so the disclosure rollforward (additions, disposals, gains and losses) ties to something on the chain. Third, a record of which block you treated as the cutoff, with its hash, so nobody can argue later about what "30 June" meant. Fourth, a way to do all of that for dozens or hundreds of addresses without somebody pasting them into a block explorer one at a time.

Most APIs are built for the first half of the first item: what is this address worth right now. That is fine for a wallet app. It is not what a close needs.

Which block is your quarter-end Bitcoin balance?

Bitcoin has no calendar. It has blocks, each carrying a timestamp the miner wrote. So "the balance at 30 June" has to be translated into "the balance after block N", and the translation depends on which midnight you mean. We looked up the last block before 23:59:59 on 30 June 2026 in three time zones a US company might report in.

For a cold wallet that did nothing that night, the choice changes nothing. For an operating wallet that pays suppliers or receives customer payments, it can move the reported quantity, and the difference is not an error on either side. It is a policy choice, and it belongs in the close memo so the same rule gets applied every quarter.

The next quarter repeated the pattern. For 30 September 2026 the last block before midnight was 969,369 in UTC, stamped 23:59:38 and followed by a 40 minute gap, then 969,391 in Eastern and 969,409 in Pacific time. That puts 22 blocks and 95,816 transactions between UTC and Eastern, and 40 blocks and 179,384 transactions between UTC and Pacific. We read all three heights on two independent explorers and got the same block hashes.

The price side moves with the same choice. On that date the hourly close was $83,556.14 at midnight UTC on Coinbase and $84,075.72 at midnight Pacific, so the timezone you pick for units should also be the one you pick for the price. Our guide to bitcoin fair value accounting price data has the full four-cutoff table.

There is a second trap inside the same window. Block timestamps are not guaranteed to increase. Block 956,159 carries a timestamp 23 seconds earlier than block 956,158, and block 956,180 is stamped 123 seconds earlier than block 956,179. Both sit inside the three hours we measured. So "the last block before the cutoff" needs a precise definition: we use the highest height whose timestamp falls at or before the cutoff, then record that height and hash. Once you have a height, every later query is pinned to it and the timestamp question never comes back.

Can a free Bitcoin API give you a balance at quarter end?

Not reliably, and the failures are silent, which is worse than an error. When we tested this, passing a height parameter to a Blockstream Esplora address call returned a byte-identical response to the call without it. You get today's balance while believing you asked for June's. Asking BlockCypher for an address state before block 300,000 returned every numeric field as zero rather than an error. Neither response tells you anything went wrong, and both would flow straight into a workpaper.

Free explorers are still the right tool for a quick look at the current state of an address, and we use mempool.space and Esplora ourselves as a second source. They are the wrong tool for a figure an auditor will re-perform.

The fix is to compute the balance from the ledger itself: every output paid to the address in a block at or below the cutoff height, minus every one of those outputs spent in a block at or below the same height. With indexed chain data that is one query. On BitcoinDatabase it runs over the documented outputs, inputs and transactions tables through the SQL endpoint, pinned to whatever height your policy produced. Our walkthrough of checking a Bitcoin address balance on a specific date goes through the method step by step.

What does ASU 2023-08 require you to disclose about bitcoin?

ASU 2023-08 applies to annual periods beginning after 15 December 2024, with early adoption permitted, so calendar-year companies are in their first full year under it. In-scope crypto assets are measured at fair value under ASC 820, with changes recorded in net income. The disclosures include, for each significant holding, the name, cost basis, fair value and number of units held, plus an annual rollforward showing additions, disposals and remeasurement gains and losses.

Look at what that list needs from a data source. Number of units at the reporting date is a balance at a height. Additions and disposals are the transactions in and out between two heights. Cost basis needs the acquisition date and amount of every lot. All of it is on the chain. None of it is in a price feed. This is general information about a published standard, not accounting advice; your auditor and your policies decide how it applies to you.

The same period-end figure travels further than the balance sheet. If the company is raising money or being sold, the bitcoin line lands in any business valuation built from those financials, and a buyer's diligence team will ask for the same height-pinned support your auditor did.

How do auditors verify Bitcoin holdings?

They split it into two questions, and an API only answers one of them. Existence and quantity: does the chain show this many bitcoin at these addresses at the cutoff. An indexed data source answers that completely, and an auditor can re-perform it against any independent explorer and get the same number to the satoshi. Control: does the company actually hold the keys to those addresses. No data API can prove that. It is typically evidenced by the company signing a message or moving a test amount from the address, and it is the company's job to produce.

Keep those separate in your workpapers. A clean on-chain balance for an address you cannot prove you control is not an asset, and a vendor that implies otherwise is overselling.

The auditor's half of the same file, a rollforward from opening to closing balance per address with the cutoff block named for each time zone, is what our Bitcoin audit trail API produces, and the tools CPA firms use for it are compared in our guide to the best crypto audit software for CPA firms.

Which Bitcoin API should a treasury team use?

Here is how the realistic options compare on the things a close depends on. Vendor details were measured on the dates shown in our other buyer guides and may have changed since.

If you already run a crypto subledger for journal entries and cost basis, it still needs a source of on-chain truth underneath it, and the question above is the one to ask that source. If you hold a handful of cold-storage addresses that never move, a free explorer checked twice at quarter end may genuinely be enough. The case for a paid data source starts when wallets are active, when the address count grows past what anyone wants to check by hand, or when an auditor starts asking you to re-perform a figure from last year. For the broader reconciliation workflow, including the two-way tie-out we run on exchange cold storage, see our guide to a Bitcoin reconciliation API for exchanges and custodians.

How do you build a quarter-end Bitcoin close that survives an audit?

Five steps, the same every quarter.

1. Write down the cutoff rule once: which time zone, and "highest height with a timestamp at or before the cutoff". Apply it mechanically.
2. Record the resulting block height and block hash in the close file before you pull any balances.
3. Pull the balance of every treasury address as of that height, and the full list of transactions between last quarter's height and this one.
4. Tie the two together: opening balance plus inflows minus outflows must equal the closing balance, to the satoshi. If it does not, you have a missing address or a missing transaction, and it is far cheaper to find it now.
5. Cross-check at least one address total against an independent public explorer. Agreement to the satoshi is the evidence your auditor wants to see.

Step four is the one that catches problems. It is also the one that is impossible without both a height-pinned balance and a complete transaction list from the same source. Our BTC address balance API covers the balance side, and the Bitcoin data API puts balances, transactions and history behind one key, over REST for your systems and SQL for the close. For the cost basis side of the same data, the crypto tax API page covers per-wallet lots.

Everything in this guide is informational on-chain data and general information about published standards. It is not accounting, tax, legal or investment advice.