A revised record is not automatically another dividend.
In our synthetic fixture, event A changes from $100 in version 1 to $110 in version 2, while event B remains $50. The selected total is $160, not $260. The rule keeps the highest unambiguous version of each expected event. These are invented records, not SCHD payment history or a broker's transaction format.
The completeness worksheet rejects duplicate event IDs because it has no revision policy. Here the input specification adds an explicit version number. That extra evidence permits replacement in a narrow test; it does not justify picking whichever real-world amount happens to be largest or most convenient.
Declare what each row represents
Each row in this fixture is a complete amount snapshot for one event in one declared source stream. It is not an additional cash movement. Event IDs A and B define the expected set. A version is a positive integer supplied as test metadata, not a timestamp inferred from file order or download time.
The first state has A version 1 at $100 and B version 1 at $50, totaling $150. The next state replaces A with version 2 at $110, totaling $110 + $50 = $160. The change in the selected total is $10. Appending the replacement amount to the old total would instead produce $150 + $110 = $260, retaining the superseded $100.
The reconciliation identity is old total − superseded amount + replacement amount: $150 − $100 + $110 = $160. That identity checks the replacement without pretending a new $110 distribution arrived. The fixture retains the original row for audit, but excludes it from the selected sum.
Row order must not determine the result
Reversing the three input rows still selects A version 2 and B version 1, with total $160. Repeating an identical A version 2 row at $110 also leaves the result at $160. Identical copies of the same version collapse to one record under this stated contract; they do not create more cash.
If A version 2 appears once at $110 and again at $120, the fixture is invalid. Both rows claim equal precedence and disagree about the amount. Our validator returns conflicting-version status and no aggregate. It does not choose $120 because it is higher, $110 because it came first, or a made-up average of $115.
| Case | Status | Known subtotal | Complete total |
|---|---|---|---|
| correction | fixture_complete | 160 | 160 |
| repeat_same_version | fixture_complete | 160 | 160 |
| reversed_input | fixture_complete | 160 | 160 |
| conflict | conflicting_version | Unknown | Unknown |
| missing_version | invalid_version | Unknown | Unknown |
| latest_unknown | incomplete | 50 | Unknown |
| zero | fixture_complete | 0 | 0 |
| missing_event | incomplete | 110 | Unknown |
Download input snapshots for every case · Download selected versions and expected totals
A missing latest amount cannot borrow an older value
Suppose A version 1 is $100, A version 2 has an unknown amount and B version 1 is $50. The latest selected A amount is unknown, so the known subtotal is only $50 and the complete total is unknown. Falling back to A version 1 would silently turn an outdated number into current evidence.
The reverse case is different: an unknown A version 1 followed by a known A version 2 at $110 can produce the complete fixture total of $160 with B at $50. It is the selected version's amount that matters. The test output preserves both its version number and its value so a reader can reproduce why one case is complete and the other is not.
Zero and invalid metadata tests
Explicitly zero amounts for both selected events produce a complete fixture total of $0. A file containing only A version 2 at $110 has a known subtotal of $110 but an unknown complete total because expected event B is absent. A missing version number is invalid metadata, even when its amount is numeric.
The test suite also rejects negative amounts and an unexpected event C. These restrictions belong to a nonnegative replacement-snapshot format, not a universal accounting rule. Every valid selected sum is checked with both decimal arithmetic and exact fractions. The CSV distinguishes blank totals from confirmed zero and keeps selected-version metadata beside the result.
What if the data is a cash-movement ledger instead?
Use a different specification. A hypothetical movement sequence of +$100, −$100 reversal, +$110 replacement cash and +$50 for another event sums to $160. Those signed movements cannot be fed into this snapshot validator, which rejects negative amounts. The two examples describe different schemas; neither establishes how a particular broker exports corrections.
Can I apply the rule to a downloaded SCHD file?
Only after establishing event identity, source authority, version semantics and the expected scope from that file's documentation. A later download date alone does not prove that a row is a newer authoritative version. This page offers no live ingestion or account access and does not assert that Schwab revised a distribution.
Evidence and scope
A public tracking-app discussion mentioning duplicate entries motivates the reader problem; its allegations are not independently verified or used as data. Investor.gov labels required assumptions separately from its outputs. The replacement rule and amounts here are independently specified tests. Fresh comparator pages already discuss input accuracy and dividend tracking. The bounded addition is this version-aware fixture, not a claim of global originality.