Why a funding rate does not match your payment

A percentage on a page is not a receipt

You copied a funding percentage from a screen, multiplied it by the amount you deposited, and the result did not match the funding entry in your account. There are several possible mismatches hidden in that one calculation. The displayed number may have been a prediction. The deposit may not have been the position value. The screenshot may belong to a different event. Even the sign may describe the paying side rather than the sign used by your statement.

The useful question is therefore narrower than “Which website is right?” Ask which actual contract event and position the payment belongs to. This guide gives you a worksheet for that check. All numbers below are hypothetical, deliberately rounded examples. They are not current funding rates, an account record or a trading strategy.

Start with the workbench if you only need a current observation. Use the process below when you need to explain a completed payment.

Keep four pieces of evidence together

These columns are separate because each can change independently. It is possible to have the correct ticker and the wrong event, or the correct final rate and the wrong notional. Do not change several inputs at once while trying to reconcile a difference; you will lose the explanation even if the resulting amount happens to look closer.

Keep the original account entry. A public dataset can help explain it, but it cannot reveal everything about your account's position or booking.

First rule out the prediction-to-settlement mismatch

A current estimate describes an unsettled observation. The actual event rate belongs to a completed settlement. Updating the current estimate after settlement does not turn it into a historical receipt.

PerpFox makes that distinction explicit. Its current Binance integration displays Coinalyze predictions and does not establish Binance actual settlement history. If you see a fresh Binance row and a blank historical series here, you have one piece of evidence, not both. Use the exchange's actual event record for reconciliation instead of treating the blank as zero.

A simple hypothetical shows why this matters. Suppose you noted +0.012% earlier, but the actual event used +0.018%. For a fixed 7,500 USDT long, the two arithmetic amounts are 0.90 and 1.35 USDT. The 0.45 USDT difference is explained by the assumed rate changing; it is not, by itself, evidence of an extra trading fee.

Then check what you multiplied the rate by

Funding calculations use position value under the contract's rules, not simply the margin deposit. Binance's funding guidance describes the payment as position value multiplied by the funding rate and explains the paying direction and event timing. Check the relevant contract rather than extending an example to inverse or differently settled products.

For this worksheet, assume a fixed 7,500 USDT notional and an actual +0.018% event rate. Convert the percentage once: 0.018 divided by 100 is 0.00018. Multiplying 7,500 by 0.00018 gives 1.35 USDT. Under our cash-flow convention the long has -1.35 and the short +1.35.

If 7,500 already represents the full position exposure, multiplying it by leverage again counts that exposure twice. Conversely, inserting only the cash you set aside as margin can understate the exposure. Write down what your input represents before comparing any totals.

This fixed-notional worksheet also holds valuation constant. An exchange statement can reflect the actual position and valuation at the event. A later screenshot of your position may not reproduce that earlier value.

Split the calculation when the size changes

A percentage sum works cleanly only when the notional stays fixed. Consider two hypothetical completed events on a long:

Adding the rates gives +0.01%. Applying that sum to the original 5,000 USDT would produce -0.50 USDT, which is not the -0.80 USDT event total. The mistake is using one size for a period in which the size changed.

PerpFox's calculator accepts one fixed notional. It does not track adds, reductions or side changes. For a changing position, calculate each event or each stretch with the appropriate constant inputs, then add cash flows with a consistent sign. Do not label a fixed-size estimate as an account reconstruction.

Align the event window before adding amounts

Our historical worksheet includes events strictly after the start and at or before the end: (start, end]. This is a calculation boundary chosen to make adjacent worksheet windows non-overlapping. It is not a promise about the exchange's exact booking mechanics.

Convert the statement and the public event list to UTC. For example, 00:00 UTC is 08:00 in a UTC+8 display. Comparing only the printed calendar date can attach an entry to the wrong day. Keep both the timestamp and its time zone in your notes.

A countdown reaching zero is also not proof that the collector has already obtained the final event. The correct next state can be “waiting for source update.” Do not use a timer boundary as a precision entry or exit instruction; consult the platform's actual timing rules if an event is relevant to your position.

Use one sign convention and separate cost categories

PerpFox shows received funding as positive cash flow and paid funding as negative. A positive rate and a positive cash flow therefore describe different things: at a positive rate, the long's funding cash flow is negative in our convention. If a statement uses debit and credit labels instead, translate those labels into your worksheet convention once.

Do not combine a funding entry with opening commission, closing commission or an assumed execution loss and call the whole amount “the funding fee.” In a hypothetical worksheet with -0.80 USDT funding, -2.00 opening cost and -2.00 closing cost, the displayed cost cash flow is -4.80 USDT. The funding component remains -0.80.

A referral-related trading-fee benefit does not give you permission to reduce a funding payment by the advertised percentage. Check what the actual benefit applies to, and enter your own account fee assumptions separately. No discount percentage is preloaded by PerpFox.

A clean-looking chart can still be incomplete

Check the obtained event count, first and last timestamp, backfill information and visible gaps. No obvious gap between the returned points does not prove that the start of the requested window was reached. A provider can return a coherent partial sequence.

Export the table you actually used. If the source later corrects an event, a saved CSV preserves which numbers your earlier calculation depended on. Compare the changed event, not only the final total. PerpFox's history table and CSV share one record set; today’s prediction is never added to fill a missing past row.

Finish with a named difference, or a named missing input

A successful reconciliation should explain the difference: prediction versus final rate, margin versus notional, size change, time window, sign convention, another fee or an absent event. “The numbers are close” is weaker evidence than an identified cause.

If you cannot obtain the applicable position value or actual event rate, leave the result unresolved. Ask the exchange about the specific account entry using its own support channel. For an error in PerpFox's displayed field or arithmetic, send a fictional reproduction through Corrections. Keep account credentials and identity information out of that report.

The calculation rules used by this site are listed in Data & calculations. For a separate question—how the rate sits beside a price move—read Funding and price: two different observations.