Yield income records: what to keep and when

Nobody thinks about record-keeping on the day they open a position. The moment it starts to matter is usually one of three: you are moving platforms, doing an annual review, or putting together filing paperwork for the first time. All three have the same shape — you are looking backwards, not saving as you go.

Looking backwards is where you meet the walls. Interest lines run into the hundreds or thousands. Timestamps do not line up with the clock you were reading. There is a stretch of the year with no entries at all. And the export itself has limits on how far back it reaches and how often you can run it. None of this is one platform behaving badly; it falls out of the shape of yield products, and it follows you wherever you go.

This piece does not tell you how anything is taxed anywhere — that is a separate matter and it varies enormously. It answers the earlier, more practical question: which records to keep, when to capture them, and in what form, so that the year is actually reconstructable on the day you need it.

Yield records are not trade records

Trades are the easy case. One buy or sell, one line, with a price, an amount and a direction. Export it and you have a clean table. Yield records are harder in three ways, and the three compound.

• The volume is different. Daily distribution means one asset alone produces three hundred-odd lines a year. Multiply by the assets and products you hold and a few thousand rows a year is ordinary.
• Some of the yield produces no line at all. More on this below — two shapes of yield leave no credit entry while you hold them, so counting entries under-counts the year systematically.
• "Redemption" is a mixed line. What lands back in your account can contain principal and rewards together. Not separating them means double-counting the rewards you were already credited.

So the default assumption — export the statement and you have your records — does not survive contact with yield products. You have to know what you are looking for before you can see what the file is missing.

Three shapes of yield, three shapes of record

Row one is the only record-friendly shape, and it is what most people assume is the whole picture. Rows two and three are where the gaps open: the money genuinely grows, but nothing in the file is labelled as income. Total up credit lines and the number you get is low — and how low depends entirely on which products you happen to hold.

When each shape pays, which balance it lands in, and why a position can look like it is earning nothing are covered separately in is Flexible savings safe, which walks through how the accrual actually works.

What a statement can and cannot give you

First thing to know: the trading statement and the earn history are normally two different exports. One comes out of your transaction history; the other has to be requested from a data download centre. Pull only the first and you will hold a file that looks thorough and contains not one line of yield.

Second, the limits — and this is the part almost everyone conflates: there are two export routes, and their caps are completely different. Taking the Binance help centre's page on downloading a spot trading transaction history statement as the worked example (checked August 2026; go by whatever the page says at the time):

• Direct export: a single window of at most six months, capped at 10,000 data points per export.
• Generated statement: reaches back up to one year from the date you pick (and no earlier than 13 July 2017), with no cap on data points — but you can generate at most five per month, and the download link is kept for seven days.
• Either route, the history is shown in UTC+0.

That distinction barely matters for trades. For yield records it decides your whole approach:

• Daily distributions are dense, so the direct route hits 10,000 fast. Across several assets even a six-month window can overflow. The answer then is not to keep slicing it thinner — it is to switch to a generated statement, which has no row cap.
• But generated statements are the scarce resource. Five a month leaves no room for trial and error, and each one reaches back only a year — so backfilling three years in December is not merely slow by this route, it is impossible.
• Exported means download it now. Seven days is not a nudge, it is a deletion. Generate without saving and you have nothing.

The earn-history side has its own caps on range, frequency and retention, and the numbers move. Do not memorise them — remember the shape of the constraint (work out which route you are on, expect a cap, save it immediately) and read the current figures off the page each time.

UTC against your own clock

The file is stamped in UTC+0; you read it in local time. Most of the year that offset is harmless. It only bites when you slice.

Cut a period for a local tax year, a fiscal year or even a calendar month, and the days either side of the boundary land in the wrong bucket — a few lines too many in one period, a few too few in the next. Because the annual total still adds up, the error is almost invisible from the summary. It only surfaces when someone asks you to justify a specific period.

The correct order is: convert every timestamp to one timezone first, then cut the period. That sounds obvious written down, and it is still not what most people do — they filter on the dates as printed.

The same timezone rule sets where the accrual day boundary falls and when distributions land, which is worth knowing before you try to reconcile a specific day.

The six fields every row needs

Whether you keep a spreadsheet or use dedicated software, a row needs all six of these. Drop any one and the period may not be reconstructable later.

1. Timestamp, with the timezone written down. Record UTC outright, or record local time and note the offset. An unlabelled timestamp becomes an unanswerable question within six months.
2. Asset. Keep same-name-different-network assets apart, and wrapped versions apart from the native one.
3. Amount at full precision. Do not round on the way in. With small daily credits the rounding error accumulates visibly.
4. Type. Subscription, redemption, reward distribution and receipt-token conversion, kept as four distinct categories. This is the field that stops principal and rewards being counted twice.
5. The reference price at the time, and the pricing convention. Which source, which moment of the day. It has to stay the same all year — a daily close today and an at-credit price tomorrow gives you a total nobody can check, including you.
6. The account involved. Which balance the movement came from and went to.

Field five is the one people skip, and it is the foundation for every cash-terms calculation you will later want to run. Why cash terms and coin terms give completely different verdicts, and when each one applies, is in coin terms vs dollar terms.

The one people miss: receipt tokens

Some staking and structured products do not pay you interest at all; they hand you a receipt token. Two designs are common, and they differ enormously in how hard they are to record:

• Rebasing, where the receipt token count grows with the rewards. Manageable — the change in count is itself the record.
• Rate-appreciating, where the count never moves but each unit redeems for more of the underlying. This produces no income entry whatsoever for the whole holding period. Your file has two lines, in and out, and every bit of the gain is hidden in the difference between them.

Which means this type needs four extra numbers captured by hand: the token count and redemption ratio going in, and the count and ratio coming out — plus a reference price at each of those two moments. Miss either end and the whole stretch is unreconstructable, and that stretch can easily span more than a year. The mechanism itself is explained in staking ETH.

Three things worth doing this month

1. Fix an export day. The last weekend of each month, say. Export monthly, save monthly. With five generated statements a month, a seven-day link and a one-year reach, leaving it until year-end runs straight into the limits.
2. Keep your own ledger. One row per movement, with the six fields above. The platform statement is the source document; your ledger is the layer you can actually audit. Interfaces get redesigned, fields get renamed, accounts get migrated — the ledger survives all of that, the export format often does not.
3. Export before you redeem or convert. Receipt-token redemptions, product retirements and campaign endings are exactly where the trail breaks. Capture the count, the ratio and what the page displayed before you act; it is far cheaper than reconstructing it afterwards.

To reverse-engineer a stretch of yield or check a platform estimate, run principal, rate and days through the earnings calculator; to see how far the simple and compound lines diverge, use the compound estimator. How long a redemption takes to land, and whether that day still accrues, is in how long Flexible redemption takes.

FAQ

Is yield income in the same statement as my trade history?

Usually not. The trading history statement and the earn history are normally two separate exports: one is generated from your transaction history, the other from a data download centre. Exporting only the trading statement leaves you with a file that contains no yield records at all. Entry names and available date ranges are per what the platform shows at the time.

There is a stretch with no interest entries at all. Was something missed?

Probably not. Two kinds of yield never produce a credit line. One accrues in place, so the balance grows without any transfer being recorded. The other is a rate-appreciating receipt token: the unit count never changes, the redemption ratio climbs, and the gain only appears as a difference when you convert back. Totalling credit lines therefore under-counts both.

The times in the export do not match what I saw on screen. Why?

Statements are shown in UTC+0 while you read them in local time. Anything that happened before the UTC day boundary in your own morning lands on the previous date in the file. When you slice a period for a local tax year or fiscal year, convert the timestamps first and split second, or the days either side of the boundary will be wrong in both periods.