A crypto funding payment depends on the position included under the contract's settlement rules. An order submission, local countdown or later flat position does not establish eligibility at the funding timestamp. Reconstruct the position from exchange fills, flag changes near the settlement boundary, then reconcile the actual funding ledger entry before declaring that a payment was avoided or received.
The difficult question is often which quantity the exchange included, rather than how to multiply a rate. A close instruction can exist before settlement while part of the position remains open. A funding record can also arrive after the screen already shows zero exposure.
This article was prepared with AI assistance, using an original hypothetical worksheet and public exchange documentation reviewed on 23 October 2026. It explains an accounting investigation, not a strategy for entering or exiting around funding. For rate estimates and later revisions, use the separate guide to predicted versus realized funding.
Separate the scheduled event from your observations
Keep three times distinct:
- Scheduled funding time: the contract's announced event time, with its timezone and interval.
- Execution time: when the exchange reports a fill that changes the position.
- Observation time: when your system receives a fill, position response or ledger record.
A fourth timestamp may describe the booked transaction. Do not silently replace the scheduled event with that value: the fields can represent different stages of processing.
Bybit says funding eligibility depends on holding a position at the funding time, and that intervals vary by pair. It also warns that opening or closing within five seconds before or after that time does not guarantee inclusion or exclusion. That warning is specific to Bybit's documented mechanism; it is not a universal tolerance for other venues. Bybit's funding timing rules are the primary reference for this example.
Treat a local position snapshot as evidence with a timestamp, not an authoritative copy of an exchange's internal settlement snapshot. A response received at 08:00:04 UTC might describe a state after the event. It cannot, by itself, prove the state used for the 08:00 event.
Reconstruct quantity from fills, not instructions
Start with a known position and apply subsequent executed changes in exchange event order. Preserve the original records as well as the reconstructed state. An order acknowledgement confirms an instruction was accepted; an unfilled order changes no position quantity.
For a simple one-way position, the worksheet can begin with a signed quantity and add each signed fill. Hedge mode needs separate long and short legs and the venue's position identifiers. Netting both legs locally may erase information needed to explain funding records.
The partial-fill inventory guide explains why requested quantity and executed quantity must remain separate. If a close request times out, resolve its actual executions through the order reconciliation process before reconstructing the boundary state.
Use three evidence labels in the worksheet:
- Reconstructed: fills suggest a quantity at the scheduled event under your stated model.
- Boundary unresolved: a nearby change, missing event or uncertain ordering prevents a reliable eligibility conclusion.
- Ledger reconciled: the booked funding cash flow has been matched and explained, within documented rounding and data limits.
These are proposed review labels. They are not exchange status codes or claims about controls available in KLINEO.
Worked example: the same closing intent, different evidence
Assume an invented USDT-linear perpetual with a scheduled event at 08:00:00 UTC. A trader holds 5 ETH long, and exchange fills reduce it by 3 ETH at 07:59:30. That leaves 2 ETH. Assume the event's applicable mark is 3,000 USDT per ETH and its final rate is positive 0.010%.
The following cases are alternative hypothetical timelines, not observed trades. The examples use Bybit's documented boundary warning; they do not assert that a particular event would be processed a particular way.
| Alternative case | Evidence for the remaining 2 ETH | Scheduled-time reconstruction | Funding conclusion |
|---|---|---|---|
| A: stable residual | No further change until a close fill at 08:00:30 | 2 ETH long | Expect a residual-position charge; match the ledger |
| B: close just before | Full remaining close reports execution at 07:59:58 | 0 ETH under a strict timestamp model | Boundary unresolved; do not conclude zero funding |
| C: instruction only | Close submitted at 07:59:58; no fill evidence yet | Last proven state is 2 ETH long | Unresolved order and eligibility; retrieve executions |
In case A, the residual notional is 2 × 3,000 = 6,000 USDT. Applying the stated decimal rate gives 6,000 × 0.00010 = 0.60 USDT paid by the long. The funding-cost ledger guide covers the broader calculation and contract-unit differences.
In case B, a simplistic backtest that assumes every fill strictly before 08:00 excludes funding would book zero. The documented processing caveat means that zero is an assumption, not evidence of the account's actual payment. Preserve the fill time and the resulting funding record together; explain any difference rather than rewriting the fill timestamp to make the model fit.
Case C is weaker still. A later flat position tells you that the close eventually happened, but supplies neither its execution time nor the quantity remaining through settlement. The maximum order quantity is not a substitute for a missing fill record.
Match the booked cash flow without reversing its sign
Retrieve funding transactions for the correct account, product, symbol and settlement asset. Keep the native transaction identifier and the original amount before normalizing it to your reporting convention.
For example, Bybit's Unified Account transaction API defines positive funding as received and negative as paid. It also separates funding from trading fees and other cash flow; for USDC perpetuals, funding and session settlement can share a record. Read the funding field rather than treating the entire record's balance change as funding. Bybit's transaction-log field definitions document these distinctions.
Under that API sign convention, a hypothetical funding = -0.60 matches case A's expected payment. A local report that displays costs as positive can show cost = +0.60, provided it preserves the original sign and states the conversion. Mixing an API receipt convention with a screen's expense convention can turn a debit into an apparent credit.
Binance USDⓈ-M Futures provides a separate FUNDING_FEE income type, with amount, asset, time and transaction identifier fields. Its documentation scopes identifier uniqueness to an income type for a user. Therefore, preserve account and record type alongside the identifier when preventing duplicate imports. Binance's income-history documentation provides the field scope; these are Binance records, not a cross-exchange schema.
A reusable event review sheet
Use one row per funding event and position leg, with linked raw evidence. The sheet should let another reviewer distinguish a modeled amount from a confirmed account transaction.
| Review item | What to retain | What it resolves |
|---|---|---|
| Event identity | Venue, account, product, symbol, leg, scheduled UTC time | Prevents matching another contract or account |
| Eligibility evidence | Starting quantity, fills, execution times, local receive times | Reconstructs exposure and exposes missing events |
| Boundary assessment | Relevant venue rule, nearby changes, unresolved gaps | Prevents false precision at the cutoff |
| Expected amount | Eligible-quantity assumption, event mark, final rate, asset | Makes the model reproducible |
| Actual transaction | Native ID, type, timestamp, original amount and sign | Establishes what was booked |
| Difference review | Amount difference, units, rounding, missing records, status | Keeps unexplained discrepancies visible |
If the expected charge is 0.60 USDT but the ledger shows 1.50 USDT, first test the quantity assumption: 5 ETH at the same invented mark and rate would produce 1.50. That is a diagnostic clue, not proof of a five-ETH snapshot. A different rate, mark, contract unit or incorrectly matched transaction can produce discrepancies too.
When an absent row proves very little
A first empty ledger response does not establish a zero payment. Check account selection, time filters, pagination and record availability before closing the review. Bybit's transaction API notes possible data delays during extreme volatility. Record when you queried and revisit an unresolved event using the venue's documented retrieval process.
Keep settled funding separate from the margin model it affects. Portfolio margin scenarios address portfolio risk offsets; those offsets do not establish which position participated in a funding event. The cross versus isolated margin guide explains the collateral boundary around the resulting account change.
The review is complete when you can explain the included exposure and booked cash flow, or clearly identify the remaining evidence gap. A precise local clock and a correct multiplication cannot fill that gap on their own.