How to Reconcile a Brokerage Feed Against Your Account Statement

When a connected feed and your broker statement disagree, the broker records win. Trade confirmations are the record of what each execution actually was, and the confirmation requirements for broker-dealers appear in 17 CFR 240.10b-10 (eCFR: https://www.ecfr.gov/current/title-17/chapter-II/part-240/section-240.10b-10), with the corresponding member firm obligation in FINRA Rule 2232, Customer Confirmations (https://www.finra.org/rules-guidance/rulebooks/finra-rules/2232). The periodic account statement is the record of period-end positions and account activity, required of member firms under FINRA Rule 2231, Customer Account Statements (https://www.finra.org/rules-guidance/rulebooks/finra-rules/2231).

A third-party feed is something different in kind. It is a copy of the broker data, normalized into whatever field names the tool uses, captured at whatever moment the last refresh happened. That makes it useful for monitoring between statements and unsuitable as the record you defend a tax position or a rule decision with.

So the reconciliation is not a hunt for which system is right. It is a check on whether the derived view still matches the authoritative one closely enough that your rules can read it. When it does not, you fix the view or you stop letting rules act on it, and you never edit the statement to match the feed.

The reason to put this in your policy rather than in your head is that reconciliation happens under mild pressure. You usually notice the mismatch because a rule just fired, and in that moment it is tempting to use whichever number lets the decision proceed.

One paragraph settles it. Name the confirmation as controlling for any single transaction, name the statement as controlling for period-end positions, cash, and basis, and name the feed as a monitoring view with no authority to settle a disagreement. Then state what happens when they disagree, which should be that rule-driven action pauses for the affected position until the difference is explained.

Add the scope question while you are there. List which accounts the feed covers and which ones it does not, because a household-level rule reading a partial feed will produce confident weights for an incomplete portfolio. Accounts you track manually belong in the list as explicit exclusions rather than as something you remember.

Pick one closed statement period and work in the same order every time. Sequence matters because the fields nest: a cash difference explains a total-value difference, and a single mismapped transaction explains both a quantity and a basis difference. Starting at the bottom means re-explaining the same defect four times.

Work top down. Compare total account value first, then cash and money-market balances, then share quantity for each position, then cost basis per lot, then each transaction line against the confirmation for date, side, quantity, and price. Stop at the first level that disagrees and resolve it before moving on, because the lower levels will often correct themselves once you do.

Keep the comparison literal. Match the statement period exactly rather than comparing a month-end statement to a feed snapshot taken days later, and write down the feed as-of timestamp next to each figure you captured. A reconciliation done against two different moments is not a reconciliation, it is two unrelated reports sitting side by side.

Most first-time reconciliations surface differences that are not errors at all. The two systems are describing the same account with different conventions, and the convention gap looks exactly like a bug until you name it.

Trade-date versus settlement-date accounting is the usual culprit for cash. A sale recorded on trade date in one view and on settlement date in the other produces a cash difference and a position difference that both disappear a few days later. Unsettled trades, pending dividends and interest, margin balances and accrued interest, and journals between your own accounts all behave the same way: ordinary items that one view has already recognized and the other has not.

Corporate actions are the usual culprit for quantity and basis. Splits, spin-offs, mergers, name and identifier changes, return-of-capital adjustments, and option assignments all require the feed to interpret an event, and interpretation is where copies drift from originals. Check whether your feed has recorded the same event the statement describes before you conclude your share count is wrong.

A large share of recurring differences are naming problems rather than data problems. A tool field called available cash may mean settled cash, total cash, or a blended buying-power number, and a field called cost basis may or may not include adjustments the broker has applied. Until the mapping is written down, every reconciliation re-discovers it.

So build the map once, field by field, and keep it with your policy. For each figure your rules read, record the tool label, the broker term it corresponds to on the statement, and anything known to be included or excluded. Then record which figure each rule actually uses, so a sizing rule cannot quietly switch denominators because a vendor renamed a column.

Pay particular attention to any funding figure, because that is where a mapping error turns into a trade problem rather than a reporting one. Whether cash is settled matters for what you can pay with, and the cash account framework for credit and payment on securities purchases sits in Regulation T, 12 CFR Part 220 (eCFR: https://www.ecfr.gov/current/title-12/chapter-II/subchapter-A/part-220), while maintenance requirements on a margin account sit in FINRA Rule 4210 (https://www.finra.org/rules-guidance/rulebooks/finra-rules/4210).

Reconciliation is only worth doing if it changes what your rules are allowed to do. The control that matters is narrow: when a decision sits near a boundary, the feed is not enough. A position within your tolerance band edge, a sizing decision at the cap, or a rebalance that depends on an exact share count gets confirmed against the statement or the broker portal before an order exists.

Away from the boundary, the feed is fine. A sleeve sitting well inside its band does not need statement-level precision to tell you to do nothing, and demanding it just means you stop reconciling at all. The point is to spend verification effort where a small data error flips the answer.

Then keep the execution step downstream of the data step, with the order instruction written in the policy rather than chosen at the order screen. Investor.gov explains that a market order is an order to buy or sell immediately, which guarantees execution but not the price, while a limit order executes only at the limit price or better and may not execute at all (Investor.gov, Types of Orders: https://www.investor.gov/introduction-investing/investing-basics/how-stock-markets-work/types-orders). After the trade, close the loop by checking the fill against the confirmation rather than against the tool.

Cost basis is the field where a feed difference costs you the most, and it is the field least likely to be caught by a glance at market value. Reconcile basis at the lot level against the broker records during the year, not in the week the forms appear.

The reporting architecture is worth reading directly so you know what you are comparing against. Brokers report proceeds and, for covered securities, cost basis on Form 1099-B (IRS, About Form 1099-B, Proceeds From Broker and Barter Exchange Transactions: https://www.irs.gov/forms-pubs/about-form-1099-b), and taxpayers report dispositions of capital assets on Form 8949 (IRS, About Form 8949, Sales and Other Dispositions of Capital Assets: https://www.irs.gov/forms-pubs/about-form-8949). Wash sales and the related basis consequences are discussed in IRS Publication 550, Investment Income and Expenses (https://www.irs.gov/publications/p550).

A legitimate difference between your records and the broker record is possible, which is exactly why the reconciliation has to happen before trading rather than after. Your own holdings across multiple accounts are wider than what any single broker reports, so keep the supporting trail for each adjustment with the confirmations and statements, and take your own facts to a qualified tax professional rather than resolving them inside a checklist.

Write each unresolved difference down in a form someone else could act on: the account number, the security identifier, the field, both values, the statement period, and the feed as-of timestamp. Then raise it with the carrying firm in writing and keep the response filed with that statement. A vague message about numbers looking off produces a vague answer months later.

Review the connection on a schedule too, not only when something breaks. Confirm the link is still read-only, confirm which accounts are in scope, and re-verify after any broker platform change, account transfer, or re-authentication prompt, since those are the moments mappings silently change. Keep the custody question separate in your notes, because SIPC describes protecting customers of its member brokerage firms when a member fails rather than protecting against a decline in the value of your securities (SIPC, What SIPC Protects: https://www.sipc.org/for-investors/what-sipc-protects).

This is the same structure Investory uses elsewhere: the rule proposes an action, the gates decide whether it proceeds, and the record shows what happened either way. A reconciliation log earns its value at the second review, when a repeated difference tells you the problem is in the mapping rather than in that particular month.