A known subtotal is not a complete dividend total.
For the hypothetical records $100, unknown and $50, the known subtotal is $150 and the complete total is unknown. Replacing the unknown with a confirmed zero gives a complete fixture total of $150. The same displayed subtotal can describe different evidence states. None of these amounts is an observed SCHD distribution.
The zero-results worksheet already distinguishes valid zero outputs from errors. This page adds a separate collection-level check: which expected records are present, which amounts are known, and whether an aggregate can be labeled complete. It does not determine your account's receipts or supply missing fund history.
Declare the set before adding amounts
This test explicitly expects event IDs A, B and C. Those labels are invented fixture identifiers, not payment dates or issuer IDs. Completeness means complete for that declared set only. It does not certify that three events represent a calendar year or all the distributions a real fund paid.
Case one provides A = $100, B = unknown and C = $50. Sum the numeric values to obtain the known subtotal: $100 + $50 = $150. Keep B on the missing list and leave the complete-total field blank with status incomplete. This preserves useful arithmetic without pretending the unresolved amount was zero.
Case two provides the same A and C but explicitly supplies B = $0. All three expected IDs now have usable numbers. The total is $100 + $0 + $50 = $150, with status fixture complete. The difference is evidence coverage, not a change in the sum. In a real audit, the zero would still need a reliable source; typing zero is not proof of a fund's payment policy.
An absent row is not the same as an empty row
If B is absent entirely, A and C still add to $150, but comparing the received IDs with A/B/C identifies missing B. If B exists with an empty amount string, the missing amount also prevents a complete total. Both cases are incomplete, yet their input records remain distinguishable in the CSV for debugging an import.
Checking only the row count fails another test. A file with A = $100, A = $100 and C = $50 has three rows, but repeats A and omits B. Blind addition produces $250, an overcount of the repeated $100 relative to the two distinct known records. Our validator labels the duplicate-ID fixture invalid and emits no numeric aggregate, rather than choosing which A row to trust.
| Case | Known subtotal | Complete total | Status | Missing IDs |
|---|---|---|---|---|
| missing_amount | 150 | Unknown | incomplete | B |
| explicit_zero | 150 | 150 | fixture_complete | None |
| absent_row | 150 | Unknown | incomplete | B |
| blank_amount | 150 | Unknown | incomplete | B |
| duplicate_id | Unknown | Unknown | invalid_ids | None |
| all_zero | 0 | 0 | fixture_complete | None |
| all_missing | 0 | Unknown | incomplete | A,B,C |
Download labeled input records · Download expected aggregate states
Keep blank outputs and confirmed zeros distinct
Three explicitly supplied zero amounts yield a complete fixture total of $0. Three unknown amounts produce a numeric known subtotal of $0 because no known dollars were added, but their complete total remains unknown. The status and missing-ID fields are therefore essential; showing only that subtotal would conceal the difference.
An explicitly empty expected set with no rows has an empty-set sum of zero. An unspecified expected set is different: its coverage cannot be checked, so the test returns unknown scope and no aggregate. Neither case proves that SCHD made no payment. The expected set must come from an independently established scope before a real import can be called complete.
Why a failed fetch must not change the arithmetic
A failed request says that this run did not retrieve evidence. It does not establish a payment of zero. Preserve the failure and any separately verified records. This worksheet has no live data-fetch routine and cannot diagnose an external provider, but its output contract prevents a missing amount from quietly entering the sum as a number.
The validator also rejects a negative incoming amount, a non-finite value and an unexpected event ID. These cases are outside this narrowly defined nonnegative-receipt fixture. A refund or correction could be legitimate in another ledger, but accepting it would require a different specification. The test file shows blank numeric outputs and the actual invalid status for these rows.
We cross-checked every valid known subtotal using decimal addition and exact fractions. The expected-output CSV contains twelve cases, including missing amount, absent ID, duplicate ID and confirmed zero. Each case preserves its expected IDs. An audit can therefore reproduce both the arithmetic and the coverage decision; matching a single dollar figure is insufficient.
Can the known subtotal be used as a full-year yield?
No. This fixture contains no dates, price, share count, tax basis or verified issuer coverage. A yield calculation needs a defined numerator and denominator. Our yield-method worksheet treats that separate question. Here the useful output is an explicitly bounded subtotal plus a completeness status.
Evidence and scope
The synthetic records and validation rules are independently specified here. A public discussion of missing tracking data is a reader-problem prompt, not proof that any provider is currently defective. Investor.gov's calculator visibly separates required inputs and assumptions; it does not supply these test amounts. Today's bounded competitor read already contains warnings about inputs and projections. Our contribution is this expected-ID aggregation fixture and its reproducible outputs, not a whole-web originality claim.
A revision needs an explicit precedence rule
The completeness checks above reject duplicates because no version contract is supplied. For a separate hypothetical replacement-snapshot format, see the version selection and conflict worksheet.
