P3: dated 1099 decisions, payment methods and the card exception (defects 23, 12, 18, D-40)
check / check (push) Canceled after 0s
check / check (push) Canceled after 0s
A vendor's 1099 decision is its own dated fact (files NEC or MISC, not reportable with its reason, or undetermined), applied by each payment's date. Payment methods are recorded; card and network payments are left out and listed; a member's check through financing counts; a bank payment with no method counts (D-40); $2,000 for payments after 2025. One worksheet for the tool, the viewer and the CPA package. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T3gXMVt7XJPi6ens1or9Dj
This commit is contained in:
77 files changed
+11455
-970
No files matched your search
+164
-48
@@ -542,8 +542,10 @@ every tool over every book in ledger-store's `tests/fixtures/old-books`.
|
||||
and card accounts due for reconciliation (`{ code, name,
|
||||
reconciled_through?, due_through, next_step }`): the cash accounts
|
||||
(`[books] cash_accounts`, else asset accounts named for cash: cash,
|
||||
bank, checking, savings, money market), the card accounts (liabilities
|
||||
named "card", before their first statement), and every other liability
|
||||
bank, checking, savings, money market), the card accounts (the
|
||||
business-card payment methods' liabilities, else liabilities named
|
||||
"card", not "gift", before their first statement:
|
||||
`ledger_core::parties::card_accounts`), and every other liability
|
||||
with a recorded statement, that have posted activity through the end of
|
||||
last month but no reconciliation (not voided) through it. The viewer's
|
||||
Needs attention uses the same rule (`ledger_store::reconcilable`).
|
||||
@@ -778,23 +780,95 @@ on from it.
|
||||
|
||||
## Tools — 1099 tracking
|
||||
|
||||
Payments are counted as cash: credits minus debits to asset accounts on
|
||||
entries tagged with the vendor. Card payments move no asset (the card
|
||||
processor's 1099-K covers them), so they drop out; reversals of tagged
|
||||
entries carry the tag and net out. Thresholds: $600 for payments through
|
||||
2025, $2,000 from 2026 (indexed for inflation after 2026); always
|
||||
overridable, always for the CPA to confirm. The books keep whether a W-9
|
||||
is on file and the TIN's last four; full TINs live only in the TIN vault
|
||||
("Tools — the TIN vault").
|
||||
What counts toward a vendor's 1099 is what left the books' cash accounts
|
||||
(`books.cash_accounts`) and financing accounts (`books.financing_accounts`)
|
||||
on entries tagged with the vendor, classified by how each payment was made
|
||||
(rules.md B-19; plan P3, defects 12, 18 and 23; D-40):
|
||||
|
||||
- out of a cash account with no payment method recorded: counts
|
||||
(presumed check, ACH or transfer; tag a debit-card payment with the
|
||||
card);
|
||||
- by card or payment network (a method of that kind, or a company card's
|
||||
account): excluded, the processor's Form 1099-K, whoever's card it was
|
||||
(Treas. Reg. §1.6041-1(a)(1)(iv));
|
||||
- through a financing account (a member paid), or the account of a
|
||||
member's or a platform's method, with no method recorded:
|
||||
undetermined, until it is (their card: excluded; their own cash or
|
||||
check: counts, the company being the payor, §1.6041-1(e)(1)).
|
||||
|
||||
Money moved between the company's own sources (the card bill, a member
|
||||
reimbursed, a loan paid down) pays no one; money received from a vendor
|
||||
for anything but a refund of what was paid (a sale, its payment of an
|
||||
invoice, a disposal, a loan) isn't netted and is listed.
|
||||
Books with no cash accounts named are refused. Thresholds: $600 for
|
||||
payments through 2025, $2,000 from 2026 (Pub. L. 119-21 §70433; indexed
|
||||
for inflation after 2026); always overridable, always for the CPA to
|
||||
confirm. The books keep whether a W-9 is on file and the TIN's last four;
|
||||
full TINs live only in the TIN vault ("Tools — the TIN vault").
|
||||
|
||||
Each vendor has a 1099 decision: `nec`, `misc`, `not_reportable` with a
|
||||
reason kind (`corporation`, `tax_exempt`, `united_states`, `state`,
|
||||
`foreign_government`, `foreign_person`, `merchandise`, `employee`, `other`)
|
||||
and the facts in words, or `undetermined` (also what a vendor nobody
|
||||
decided on reads as). Each is recorded with who decided and when, and the
|
||||
date it takes effect, or none (from the beginning: the vendor's status
|
||||
all along, and every decision written before decisions were kept). Each
|
||||
payment takes the decision in force on its date (its reversal chain's
|
||||
first entry's).
|
||||
|
||||
- `books.list_vendors {}` → `{ vendors: [{ id, name, form_1099?,
|
||||
tin_on_file, party_id }] }`.
|
||||
- `books.set_vendor_1099 { vendor, form_1099: "nec" | "misc" | "none",
|
||||
tin_on_file? }` → the vendor. `vendor` is an id or a name.
|
||||
decision_1099, decisions_1099, tin_on_file, party_id }] }`.
|
||||
`decision_1099` is the decision in force today, `{ value, reason_kind?,
|
||||
reason?, authority?, effective?, decided_by?, decided_on?, citation?,
|
||||
note? }` (`authority`: the rule that exempts the reason kind; no
|
||||
`decided_by`: nobody decided); `decisions_1099` every recorded
|
||||
decision, in date order; `form_1099` "1099-NEC" or "1099-MISC" when
|
||||
today's decision files one.
|
||||
- `books.set_vendor_1099 { vendor, form_1099?, reason_kind?, reason?,
|
||||
effective?, tin_on_file?, decided_by?, decided_on?, citation?, note? }`
|
||||
→ the vendor, with `changed` ("set", "removed", "unchanged") and
|
||||
`warnings`. `vendor` is an id or a name. With `form_1099` (`nec`,
|
||||
`misc`, `not_reportable`, `undetermined`), `decided_by` is required
|
||||
(`decided_on` defaults to today); `not_reportable` takes `reason_kind`
|
||||
and `reason` (`other` a `citation` too), no other value takes them.
|
||||
"none" is refused, saying what to say instead; paid by card is never a
|
||||
reason. `effective` (YYYY-MM-DD) only when the payee's status changed:
|
||||
an LLC's corporate election from its Form 8832 date; a payee that
|
||||
incorporates is a new vendor. A dated decision with nothing decided
|
||||
before it is refused; one the same as the decision before its date
|
||||
takes out any decision recorded for that date ("removed"); recorded
|
||||
again exactly so, nothing is journaled ("unchanged"). Without
|
||||
`form_1099`, `tin_on_file` alone marks the W-9, keeping the decision and
|
||||
who made it; `tin_on_file` omitted keeps the flag. `warnings` names each
|
||||
year (and its entries) whose payments the change reaches in a closed
|
||||
period or after that year's 1099s were due (January 31 of the next
|
||||
year): tell the human, a filed 1099 may need correcting. Journaled as
|
||||
`vendor.1099_set` (a W-9 flag alone as `vendor.w9_flag_set`), after a
|
||||
`journal.format_set` declaring the `vendor_1099_decisions` feature once.
|
||||
- `books.add_instrument { kind, label, last4?, owner_party?, account }` →
|
||||
`{ id, kind, card_or_network, label, last4?, owner_party?, account_id,
|
||||
account, warnings }`. `kind`: `bank` (the company's checks, ACH, wires,
|
||||
bill-pay), `business_card` (a company card the payee charged),
|
||||
`member_card` (a member's personal card the payee charged),
|
||||
`member_cash_or_check` (a member's own cash, check, ACH, Zelle, or a
|
||||
friends-and-family transfer), `platform` (paid to the payee as a seller
|
||||
through PayPal or Venmo goods and services; never ACH, bill-pay, Zelle or
|
||||
friends-and-family). `account` (id or code) is what it pays through: the
|
||||
bank account, the card's liability, Due to Members for a member's own
|
||||
card or cash; an asset or liability, not a header, not payables or
|
||||
receivables. `label` is unique (ignoring case); `last4` exactly four
|
||||
digits. Journaled as `instrument.added` (feature `payment_instruments`).
|
||||
- `books.instruments {}` → `{ instruments: [...] }`, by id. Read-only.
|
||||
- `books.set_entry_instrument { entry_id, instrument? }` → the entry (as
|
||||
`books.get_entry`), with `changed` and `warnings` (as above). An id or
|
||||
label; omit to clear. Metadata only: drafts and posted entries alike;
|
||||
the entry and its reversals are tagged together. Journaled as
|
||||
`entry.instrument_set`.
|
||||
- `books.set_entry_vendor { entry_id, vendor? }` → the entry (as
|
||||
`books.get_entry`, which now shows `vendor`). Omitting `vendor` clears
|
||||
the tag. Metadata only: posted entries may be tagged. `books.draft_entry`
|
||||
takes `vendor` too; bills and their payments are tagged automatically.
|
||||
`books.get_entry`, which shows `vendor`, and `instrument` and
|
||||
`instrument_id`). Omitting `vendor` clears the tag. Metadata only:
|
||||
posted entries may be tagged. `books.draft_entry` takes `vendor` and
|
||||
`instrument` too; bills and their payments are tagged automatically.
|
||||
`books.set_entry_party` tags the vendor too when the party has a vendor
|
||||
record, so tagging by party counts for 1099s the same way. On an entry
|
||||
naming several parties the parties are `books.set_entry_party`'s:
|
||||
@@ -802,27 +876,60 @@ is on file and the TIN's last four; full TINs live only in the TIN vault
|
||||
is; tagging a vendor whose party isn't named, or clearing the tag while
|
||||
its party is named, is refused (drop or add the party with `parties`
|
||||
instead). An entry and its reversal always carry the same tags.
|
||||
- `books.vendor_1099 { year, threshold?, include_tins?, csv? }` →
|
||||
`{ year, threshold, vendors: [{ vendor_id, name, form_1099?, tin_on_file,
|
||||
paid, reportable, party_id?, tin_last4?, tin?, tin_type?, tin_note? }],
|
||||
missing_w9, notes, warning?, csv? }`. For a year whose threshold
|
||||
- `books.vendor_1099 { year, threshold?, include_tins?, csv?,
|
||||
cash_accounts?, financing_accounts?, through? }` →
|
||||
`{ year, threshold, vendors: [{ vendor_id, name, form_1099?,
|
||||
decision_1099, decisions_in_year, tin_on_file, paid, excluded_card,
|
||||
undetermined, not_reportable, status, decision_needed, reportable,
|
||||
party_id?, tin_last4?, tin?, tin_type?, tin_note? }], missing_w9,
|
||||
excluded_card_payments, undetermined_payments, other_receipts,
|
||||
untagged_entries, unresolved, notes, warning?, csv? }`. `paid` is what
|
||||
counts toward the 1099; `excluded_card` what a card or network paid;
|
||||
`undetermined` what waits on its payment method; `not_reportable` what
|
||||
was paid while the vendor was decided not reportable. `status`:
|
||||
`reportable` (file one: what counts reaches the threshold however the
|
||||
unknowns settle), `under_threshold`, `not_reportable`, or
|
||||
`undetermined` (a decision or a method is needed first;
|
||||
`decision_needed` says which); `reportable` is `status = reportable`.
|
||||
Each payment list is `[{ entry_id, date, vendor_id, vendor, amount,
|
||||
instrument? }]`. `missing_w9` names the vendors a 1099 is or may be
|
||||
("(may be reportable)") due for without a W-9. The notes are quiet:
|
||||
untagged entries are one count (those that paid money out for
|
||||
something) with the tool to tag them. For a year whose threshold
|
||||
wanderbooks doesn't know (after 2026 until the indexed amount is added)
|
||||
it refuses with what to do; pass `threshold` explicitly once the figure
|
||||
is confirmed. On an entry naming several parties, `paid` counts only
|
||||
the vendor's resolved share of the payment (rules.md B-19); an entry
|
||||
whose shares don't resolve counts in full and `notes` names it.
|
||||
`tin_last4` comes from the party's W-9 facts. With
|
||||
`include_tins: true` (default false) each line carries `tin`, the full
|
||||
TIN formatted as the IRS writes it (123-45-6789; 12-3456789 for an
|
||||
EIN), and `tin_type`, read from the vault, or `tin_note` saying why not
|
||||
(not in the vault, the vault locked, a record whose last four or hash
|
||||
disagree with the books); `warning` then says "This worksheet holds
|
||||
full TINs, for the CPA; keep it out of the books.". This is the only
|
||||
tool output that ever holds a full TIN. `csv: true` (default false)
|
||||
also hands the worksheet over as a CSV file, `csv` (a `HandedFile`,
|
||||
"Tools — the TIN vault"), named `1099-worksheet-<year>.csv`, or
|
||||
`1099-worksheet-<year>-with-tins.csv` with `include_tins` (TINs only
|
||||
then).
|
||||
it refuses with what to do; pass `threshold` explicitly once the
|
||||
figure is confirmed. Payments are counted out of `cash_accounts` and
|
||||
`financing_accounts` (account codes; each defaults to the `[books]`
|
||||
setting, the CPA package's rule: `ledger_package::Settings::with_accounts`;
|
||||
a code the chart lacks is refused), from January 1 of `year` through
|
||||
`through` when given (`YYYY-MM-DD`, a day of `year`: the worksheet as of
|
||||
a day, rules.md B-33), else the whole year. On an entry naming several
|
||||
parties, the buckets count only the vendor's resolved share of the
|
||||
payment, split across them to the cent (rules.md B-19); an entry whose
|
||||
shares don't resolve counts in full and `notes` names it. `tin_last4`
|
||||
is the party's TIN facts' last four, else its W-9 facts'
|
||||
(`Party::tin_last4`). With `include_tins: true` (default false) each
|
||||
line carries `tin`, the full TIN formatted as the IRS writes it (123-45-6789;
|
||||
12-3456789 for an EIN), and `tin_type`, read from the vault, or
|
||||
`tin_note` saying why not (not in the vault, the vault locked, a record
|
||||
whose last four or hash disagree with the books); `warning` then says
|
||||
"This worksheet holds full TINs, for the CPA; keep it out of the
|
||||
books.". This is the only tool output that ever holds a full TIN.
|
||||
`csv: true` (default false) also hands the worksheet over as a CSV file,
|
||||
`csv` (a `HandedFile`, "Tools — the TIN vault"), named
|
||||
`1099-worksheet-<year>.csv`, or `1099-worksheet-<year>-with-tins.csv`
|
||||
with `include_tins` (TINs only then): `vendor_id, name, decision_1099,
|
||||
form_1099, reason_kind, reason, decided_by, decided_on, effective,
|
||||
decisions_in_year, paid, excluded_card, undetermined, not_reportable,
|
||||
status, reportable, w9_on_file, tin_last4` (and `tin, tin_type,
|
||||
tin_note`). The CPA package carries the same CSV: one list of cash
|
||||
accounts and one of financing accounts per package, the request's, else
|
||||
the settings', for every file in it (R18), the 1099 worksheet through
|
||||
the package's `as_of`; so `books.vendor_1099` given the package's
|
||||
`cash_accounts`, `financing_accounts` and `through` = `as_of` (and its
|
||||
`include_tins`) hands over the package's `1099-worksheet-<year>.csv`
|
||||
byte for byte (the tool names one with TINs `-with-tins`; checked by `ledger-mcp` `oracle_mcp.rs`
|
||||
`cpa_package_holds_the_year_and_its_evidence`).
|
||||
|
||||
## Tools — parties
|
||||
|
||||
@@ -875,8 +982,8 @@ texts are at most 500 characters, no control characters.
|
||||
w9_content_base64?, w9_sha256?, w9_file_name? }` or `{ party, clear:
|
||||
true }` → the party. Journaled as `party.w9_set`. A party with a
|
||||
vendor record also gets the record's `tin_on_file` set to match
|
||||
(journaled as `vendor.1099_set`), so `books.vendor_1099`'s
|
||||
`missing_w9` follows.
|
||||
(journaled as `vendor.w9_flag_set`, its 1099 decision and who made it
|
||||
kept), so `books.vendor_1099`'s `missing_w9` follows.
|
||||
`tin` and `tin_type` put the full TIN in the TIN vault, and the signed
|
||||
form (`w9_upload_id`, or `w9_content_base64` with `w9_sha256`, as in
|
||||
"Tools — receipts & documents") goes there too (below); with them
|
||||
@@ -992,8 +1099,11 @@ rules.md B-35):
|
||||
posted entries dated in the year count.
|
||||
- *Money accounts* (B-35 item 5, P3 defect 24): the `[books]
|
||||
cash_accounts` (every asset account but receivables when none are set),
|
||||
the cards (liability accounts whose names say "card", not "gift card":
|
||||
the rule the reconciliation reminders read), and the `[books]
|
||||
the cards (the business-card payment methods' liability accounts,
|
||||
`books.instruments`; while the books record none, the liability
|
||||
accounts whose names say "card", not "gift card"; never a member's
|
||||
card or a platform's account: the one rule the reconciliation reminders
|
||||
and the viewer read), and the `[books]
|
||||
financing_accounts` (what the members advanced, loans). Any other
|
||||
liability (an accrued expense, deferred revenue, gift cards sold,
|
||||
distributions payable) is a promise, counted when it is settled, never
|
||||
@@ -1022,9 +1132,11 @@ rules.md B-35):
|
||||
- `invoiced` / `billed`: its invoices' and bills' totals dated in the year.
|
||||
`owed` / `receivable`: its open bills' and invoices' balances now (every
|
||||
year).
|
||||
- `amount_1099` (vendor parties only): what `books.vendor_1099` counts as
|
||||
paid to its vendor record in the year (asset accounts only, so card
|
||||
payments drop out); `form_1099` is the record's mark.
|
||||
- `amount_1099` (vendor parties only): what `books.vendor_1099` counts
|
||||
toward its vendor record's 1099 in the year (its `paid`: card and
|
||||
network payments excluded, member payments with no method recorded
|
||||
undetermined; absent when the worksheet can't be made); `form_1099` and
|
||||
`decision_1099` are the record's decision in force today.
|
||||
- `gross_pay` / `net_pay`: payroll lines naming it, in the year.
|
||||
|
||||
## Tools — the TIN vault
|
||||
@@ -1400,7 +1512,8 @@ posting.
|
||||
matches accounts by name (tell a CPA who imported an earlier IIF), says
|
||||
when sub-accounts' full names change with it, when the new name moves
|
||||
the account into or out of the cash accounts (`books.cash_accounts`
|
||||
unset: picked by name) or the card accounts (named "card"), and lists
|
||||
unset: picked by name) or the card accounts (named "card", while no
|
||||
business-card payment method is recorded), and lists
|
||||
conventions whose text names the old name.
|
||||
- `books.set_tax_category { account, category?, deductible_percent? }`:
|
||||
map a revenue or expense account to a category (null clears),
|
||||
@@ -1711,10 +1824,13 @@ entries.
|
||||
member role, as the viewer's capital statement finds it; with none, the
|
||||
member's TIN is a gap.
|
||||
**1099 worksheet** (`1099-worksheet-<year>.csv`, `as_of`'s calendar
|
||||
year): the payments from January 1 through `as_of` (the year to date;
|
||||
the whole year for a December 31 package; DECISION D-36), and the
|
||||
README says which. With TINs it adds `party_id, tin_last4, tin,
|
||||
tin_type, tin_note`. A zip with the full set, each
|
||||
year) is `books.vendor_1099`'s CSV (above) for the package's cash and
|
||||
financing accounts: the payments from January 1 through `as_of` (the
|
||||
year to date; the whole year for a December 31 package; DECISION D-36),
|
||||
and the README says which. `books.vendor_1099` given the same
|
||||
`cash_accounts`, `financing_accounts` and `through` hands over the
|
||||
identical file. With TINs it adds `tin, tin_type, tin_note`. A zip with
|
||||
the full set, each
|
||||
statement as PDF and XLSX: `profit-and-loss`, `balance-sheet`,
|
||||
`cash-flow` (the direct method, as `books.export` prints it: operating
|
||||
by class, investing and financing by kind with each member named, and
|
||||
|
||||
@@ -395,7 +395,9 @@ by default; `statement_attachment` + `confirmed: true` records it),
|
||||
reconciliation`; `books.digest` `unreconciled_accounts` and the
|
||||
viewer's Needs attention, one rule (`ledger_store::reconcilable`): the
|
||||
cash accounts (`[books] cash_accounts`, else assets named for cash), the
|
||||
card accounts (liabilities named "card", before their first statement),
|
||||
card accounts (`ledger_core::parties::card_accounts`: the business-card
|
||||
payment methods' liabilities, else the liabilities named "card", not
|
||||
"gift", before their first statement),
|
||||
and other liabilities with statements, not reconciled through last
|
||||
month's end). The statement of a reconciliation not voided can't be
|
||||
unlinked from it.
|
||||
|
||||
+261
-52
@@ -737,26 +737,131 @@ invoice or bill (a real prepayment is a deposit): DECISIONS (the owner,
|
||||
`aging_as_of_a_date_sees_only_what_existed_then`,
|
||||
`a_payment_never_predates_its_document`.
|
||||
|
||||
## B-19 1099 reporting thresholds
|
||||
## B-19 1099 reporting thresholds, payment methods, and decisions
|
||||
|
||||
**Status:** AUTHORITY (`sources/irs-1099-thresholds.md`)
|
||||
**Status:** AUTHORITY (`sources/irs-1099-thresholds.md`,
|
||||
`sources/irs-1099-payment-method.md`), with the DECISIONs named below.
|
||||
|
||||
$600 through 2025; $2,000 for payments made after Dec. 31, 2025 (26 U.S.C.
|
||||
§6041(a), §6041A(a)(2), as amended by Pub. L. 119-21 §70433); for calendar
|
||||
years after 2026, indexed to inflation and rounded to the nearest $100
|
||||
(§6041(h)). Card payments are reported on Form 1099-K, not 1099-NEC/MISC.
|
||||
Attorneys' gross proceeds stay at $600 (not modeled).
|
||||
§6041(a), §6041A(a)(2), as amended by Pub. L. 119-21 §70433; §70433(f):
|
||||
"shall apply with respect to payments made after December 31, 2025"); for
|
||||
calendar years after 2026, indexed to inflation and rounded to the nearest
|
||||
$100 (§6041(h)). §70433 sets the one amount for Form 1099-NEC
|
||||
(§6041A(a)(2), §70433(c)) and the §6041(a) payments on 1099-MISC alike.
|
||||
Gross proceeds paid to an attorney (a payment in connection with legal
|
||||
services that §6041 doesn't cover, a settlement paid to a claimant's
|
||||
attorney, say: attorneys' fees for the company's own legal work are
|
||||
§6041's, on Form 1099-NEC) stay at $600 (Treas. Reg. §1.6045-5(a)(1),
|
||||
(c)(4)), and royalties report at $10 (§6050N(a)); neither is modeled, and
|
||||
the worksheet says so.
|
||||
|
||||
What counts as paid: payments made in the calendar year (§6041(a)), so a
|
||||
prepayment counts when made. A worksheet as of a day (the CPA package's,
|
||||
B-33) counts the year's payments from January 1 through that day. The
|
||||
engine counts credits minus debits to the payment sources on a vendor's
|
||||
tagged entries: `[books] cash_accounts` and `financing_accounts` (a
|
||||
member or lender paying on the company's behalf; the company is still the
|
||||
payer). A card charge leaves neither (1099-K); a
|
||||
bill is not paid until it is (`form1099::vendor_1099_report_with`,
|
||||
checked by `payments_come_from_cash_and_financing_only`). A W-9 is on
|
||||
file by the vendor's flag or its party's W-9 facts.
|
||||
**Who pays.** The payor is the person engaged in a trade or business who
|
||||
makes the payment in its course (Treas. Reg. §1.6041-1(a)(1)(i)). A person
|
||||
paying on behalf of another is the payor only if it performs management
|
||||
or oversight functions in connection with the payment or has a
|
||||
significant economic interest in it; "mere administrative or ministerial
|
||||
functions such as writing checks at another's direction" are neither
|
||||
(§1.6041-1(e)(1)). A member who pays a company bill from their own funds
|
||||
at the company's direction, the company bearing the cost through Due to
|
||||
Members, does only that: the company stays the payor, so a member's own
|
||||
cash, check or transfer through a financing account counts.
|
||||
|
||||
**What is paid by card or network.** A transaction reportable under both
|
||||
§6041 and §6050W "[is] reported under section 6050W and not section
|
||||
6041", and for that test the third-party-network de minimis is
|
||||
disregarded (§1.6041-1(a)(1)(iv); the 1099-MISC/NEC instructions, "Form
|
||||
1099-K"). A payment card is "any card, including any stored-value card"
|
||||
(§1.6050W-1(b)(3)); the IRS names credit, debit and stored-value cards
|
||||
("Understanding your Form 1099-K"). The exclusion follows the instrument,
|
||||
whoever's card it was: a member's personal card is excluded too. A payment
|
||||
card transaction is one in which the card "is accepted as payment"
|
||||
(§1.6050W-1(b)(1)) by the payee: a card that only funded a transfer the
|
||||
payee didn't take as a card payment is not one (a member's
|
||||
friends-and-family transfer is their cash). Automated clearing houses
|
||||
"do not qualify as TPSOs" (Instructions for Form 1099-K): ACH, bill-pay
|
||||
and Zelle are bank payments, not network payments.
|
||||
|
||||
**The rule (`form1099::vendor_1099_report`, `kernel::payment_bucket`).**
|
||||
Payment methods are recorded once (`instrument.added`: bank,
|
||||
business_card, member_card, member_cash_or_check, platform, each with the
|
||||
account it pays through) and entries tagged with the one they were paid
|
||||
with (`entry.instrument_set`, the reversal chain together). Each line of
|
||||
a vendor-tagged posted entry has a role from its account: cash
|
||||
(`books.cash_accounts`), financing (`books.financing_accounts`, and the
|
||||
account of a member_card, member_cash_or_check or platform method: only
|
||||
the entry's method says how a payment through it was made), a company
|
||||
card's account (a business_card method's), or other. First match wins:
|
||||
|
||||
| The line | Bucket |
|
||||
|---|---|
|
||||
| the entry's method pays through this line's account, card or network | card (excluded) |
|
||||
| the entry's method pays through this line's account, bank or a member's own cash or check | counts |
|
||||
| a cash account (no method, or one naming another account) | counts: presumed check, ACH or transfer (DECISION D-40, owner, 2026-10-20); tag a debit-card payment with the card |
|
||||
| a financing account, or a member's or platform method's account (no method, or one naming another account) | undetermined until the method is recorded |
|
||||
| a company card's account (a business_card method's) | card (excluded) |
|
||||
| anything else (an expense, payables, prepaid) | no payment line |
|
||||
|
||||
Each entry's buckets are netted (`kernel::net_buckets`, P3 review R1):
|
||||
money moved between the company's own sources pays no one, so the card
|
||||
bill (Dr card / Cr bank), a member reimbursed (Dr Due to Members / Cr
|
||||
bank) and a loan's principal net to zero; when the signs differ, the net
|
||||
goes to the one bucket with its sign, else to undetermined. A bill is not
|
||||
paid until it is; a prepayment counts when made (payments made in the
|
||||
calendar year, §6041(a)); a worksheet as of a day (the CPA package's,
|
||||
B-33) counts the year's payments from January 1 through that day; a
|
||||
refund and a reversal net. Money received from a vendor for something else (the entry nets money
|
||||
in and credits, beside its payment lines, anything a refund of what was
|
||||
paid doesn't: revenue, receivables, a registered asset's cost account,
|
||||
equity, or a liability other than payables; a sale, a customer's payment,
|
||||
a disposal, a loan) is left out and listed, with its reversals (P3 review
|
||||
R6); a refund credits only an expense, payables, or an asset no money is
|
||||
paid out of and no one owes (prepaid, a deposit).
|
||||
Books with no cash accounts named are refused (never "every asset", P3
|
||||
review R5), as are books in another currency without a threshold given.
|
||||
With cash accounts named and no methods or financing accounts, what counts
|
||||
is exactly the old figure (credits minus debits to cash), but for money
|
||||
received for something else.
|
||||
|
||||
**The decision.** Each vendor's 1099 decision is nec, misc,
|
||||
not_reportable with a reason kind and the facts in words, or undetermined;
|
||||
"not reportable" is never "undetermined" (plan defects 18, 23). No return
|
||||
is required for payments of bills for merchandise, telephone, freight,
|
||||
storage and similar (§1.6041-3(c)), or to a corporation (§1.6041-3(p)(1),
|
||||
except attorneys' fees and medical and health care; a payor may treat a
|
||||
payee as a corporation by its name "Incorporated, Inc., Corporation,
|
||||
Corp., P.C., (but not Company or Co.)", a W-9 or a corporate resolution:
|
||||
§1.6049-4(c)(1)(ii)(A)), a tax-exempt organization ((p)(2)), the United
|
||||
States ((p)(3)), a State or its political subdivision ((p)(4)), a foreign
|
||||
government ((p)(5)) or a documented foreign payee (§1.6041-4(a)(1)); an
|
||||
employee's wages go on Form W-2 (§1.6041-2(a)(1)). Paid by card is never a
|
||||
vendor's reason: it is a property of each payment. Every new decision
|
||||
names who made it and when (`settings::Source`).
|
||||
|
||||
**Dated decisions** (DECISION D-40, owner, 2026-10-20: "legally this has
|
||||
to be 2 dated statuses"). Each decision takes effect on a date (a W-9's,
|
||||
or a tax election's: Form 8832's effective date, §301.7701-3(c)(1)(iii)),
|
||||
or from the beginning; each payment takes the decision in force on its
|
||||
reversal chain's first entry's date. An LLC electing corporate taxation
|
||||
keeps its EIN and its vendor record and changes on the election's date; a
|
||||
payee that incorporates is a new legal person, a new vendor with its own
|
||||
W-9. A decision written before decisions were kept (no date, no source)
|
||||
is in force from the beginning, and an old null reads undetermined (plan
|
||||
5.5). A dated decision with nothing decided before it is refused (it would
|
||||
leave every earlier payment undetermined); one the same as the decision
|
||||
before its date takes out any decision recorded for that date. A change
|
||||
reaching payments in a closed period, or in a year whose 1099s were due
|
||||
(January 31 of the next year), warns in `books.set_vendor_1099` and
|
||||
`books.set_entry_instrument`.
|
||||
|
||||
**Status** (per vendor and year; T the threshold, F the payments made
|
||||
while decided for a 1099, U those while undetermined, lo/hi each with
|
||||
every reversal chain's unknown settled low or high, P3 review R3):
|
||||
nothing in F or U is not_reportable when something was paid while not
|
||||
reportable or the year-end decision is, else under_threshold; anything in
|
||||
U is undetermined when hi(F) + max(hi(U), 0) ≥ T (a decision is needed),
|
||||
else under_threshold; otherwise reportable when lo(F) ≥ T, under_threshold
|
||||
when hi(F) < T, else undetermined. `reportable` is `status = reportable`.
|
||||
A W-9 is on file by the vendor's flag or its party's W-9 facts.
|
||||
|
||||
An entry naming several parties (a payment shared between a contractor
|
||||
and a member; `ledger_core::shares`) counts only the vendor's share
|
||||
@@ -769,10 +874,13 @@ the same target the MCP server checks shares against, then scaled to the
|
||||
negates both the payment and the target): the share unchanged when the
|
||||
payment equals the target (the usual case, an expense paid from cash or
|
||||
by a member), else payment × share ÷ target, rounded to the nearest cent,
|
||||
half away from zero (so a part charged to a card scales out, 1099-K). A
|
||||
percent split's leftover cent goes to the party named first (shares
|
||||
INVARIANT 8). A reversal carries the shares and subtracts the same part,
|
||||
and re-apportioning either one re-apportions the other
|
||||
half away from zero (so a part on a card no method names scales out). The
|
||||
vendor's part is split across the entry's netted buckets in proportion,
|
||||
each rounded down to the cent and the cents short handed out by largest
|
||||
remainder (`kernel::apportion`, P3 review R12), so they sum to it
|
||||
exactly. A percent split's leftover cent goes to the party named first
|
||||
(shares INVARIANT 8). A reversal carries the shares and subtracts the
|
||||
same part, and re-apportioning either one re-apportions the other
|
||||
(`Ledger::set_entry_parties` INVARIANT 5), so the pair nets to zero. The
|
||||
vendor tag follows the parties: on an entry naming several,
|
||||
`set_entry_vendor` never replaces their shares (refused unless the
|
||||
@@ -784,22 +892,66 @@ named beside another vendor (`add_vendor`), checked by
|
||||
`a_named_party_gaining_a_vendor_record_keeps_one_vendor_per_entry`.
|
||||
Shares that don't resolve count the whole payment toward the vendor (the
|
||||
conservative answer) and the entry is listed (`Vendor1099Report::
|
||||
unresolved`; a `books.vendor_1099` note). An entry naming one party
|
||||
counts as before (`form1099::vendor_1099_report_with_members`, checked
|
||||
by `a_shared_payment_counts_the_vendors_share`,
|
||||
`a_percent_split_gives_the_leftover_cent_to_the_first`,
|
||||
`a_reversed_shared_payment_nets_to_zero`,
|
||||
`a_shared_payment_partly_on_a_card_scales_to_the_payment`,
|
||||
`unresolved_shares_count_in_full_and_are_listed`). DECISION (the owner,
|
||||
unresolved`; a `books.vendor_1099` note). DECISION (the owner,
|
||||
2026-10-15: shares).
|
||||
|
||||
**The quieter note.** Untagged posted entries are named only when they
|
||||
paid money out (netted counts plus undetermined above zero) for something
|
||||
(a debit to an expense, to payables, or to an asset no money is paid out
|
||||
of and no one owes), leaving out payroll runs, entries marked as having
|
||||
no counterparty, entries naming only parties with no 1099 role, and
|
||||
entries reversed in the year (P3 review R7): one count, the entries when
|
||||
ten or fewer, and the tool to tag them.
|
||||
|
||||
**Cards and party totals.** The worksheet's card accounts are the
|
||||
business-card methods' accounts only. Party money's cards are the same
|
||||
once one is recorded (B-35 item 5: `parties::card_accounts`), and, while
|
||||
none is, the liabilities named "card"; a charge to such a card leaves no
|
||||
cash or financing account, so the worksheet counts it for no one either
|
||||
way, and lists it as a card's only once the card is recorded. The
|
||||
worksheet is never a party's totals: B-35 item 9 says how the two relate
|
||||
(a member paying a payee through the members' financing is paid to the
|
||||
payee in party totals, and the company's payment here), and they never
|
||||
contradict.
|
||||
|
||||
**Enforced:** `form1099::default_threshold`, a dated rule
|
||||
(`ledger_core::rules::THRESHOLD_1099`, known through 2026, review from
|
||||
2026-11-01). For a later year the engine refuses with `RuleNotKnown`
|
||||
rather than guess; the MCP digest and the viewer's "Needs attention" list
|
||||
flag the rule once it is due (DECISION, the owner, 2026-10-13). **Checked:**
|
||||
flag the rule once it is due (DECISION, the owner, 2026-10-13). The
|
||||
bucket table is `kernel::payment_bucket` (Kani `payment_bucket_is_the_table`,
|
||||
`payment_split_is_exact`, `net_buckets_keeps_the_total`). **Checked:**
|
||||
`an_unknown_year_threshold_is_never_guessed`,
|
||||
`dated_rules_go_stale_on_their_review_date`, MCP stdio test.
|
||||
`dated_rules_go_stale_on_their_review_date`,
|
||||
`the_report_needs_the_cash_accounts_and_dollars`,
|
||||
`payments_come_from_cash_and_financing_only`,
|
||||
`undecided_is_not_not_reportable`,
|
||||
`a_members_personal_card_payment_is_not_a_1099_payment`,
|
||||
`card_account_payments_are_listed_not_dropped`,
|
||||
`a_debit_card_payment_from_the_bank_is_excluded_when_tagged`,
|
||||
`a_tag_naming_another_account_is_undetermined`,
|
||||
`paying_down_a_financing_liability_pays_no_vendor`,
|
||||
`paying_the_card_bill_pays_no_vendor`,
|
||||
`a_negative_unknown_keeps_a_reportable_vendor_undetermined`,
|
||||
`a_sale_to_a_contractor_does_not_lower_its_1099`,
|
||||
`money_from_a_vendor_that_is_no_refund_does_not_lower_its_1099`,
|
||||
`a_status_change_mid_year_applies_by_payment_date`,
|
||||
`two_status_changes_in_a_year_and_a_reversal_across_them`,
|
||||
`an_incorporation_on_december_30_is_a_new_vendor`,
|
||||
`an_llc_electing_corporate_taxation_keeps_its_vendor`,
|
||||
`a_dated_decision_records_a_change`,
|
||||
`a_decision_change_names_the_payments_it_reaches`,
|
||||
`an_undated_old_decision_is_in_force_from_the_beginning`,
|
||||
`payment_bucket_is_the_table_in_all_16_cases`,
|
||||
`a_shared_payment_splits_across_buckets_to_the_cent`, the properties
|
||||
`no_instruments_no_financing_is_the_old_report`,
|
||||
`buckets_partition_each_payment`, `a_reversal_nets_every_bucket_to_zero`,
|
||||
`the_worksheet_ties_to_the_ledger`, `party_totals_are_the_1099s_buckets`
|
||||
(ledger-core `tests/form1099.rs`);
|
||||
`the_untagged_note_counts_only_money_out`,
|
||||
`the_other_receipts_note_says_what_each_entry_did` (ledger-package); the
|
||||
MCP stdio tests; bookspec
|
||||
`bookspec/examples/1099-*.toml`.
|
||||
|
||||
## B-20 Every transaction has supporting documents; records are kept
|
||||
|
||||
@@ -1096,13 +1248,23 @@ writer declares it once, in the `journal.format_set` just before the
|
||||
first line that needs it, with the format in force (at least 2) and the
|
||||
features already in force (`Store::ensure_feature`): an earlier reader
|
||||
stops at the declaration, and books that never use the feature stay
|
||||
readable by it. P3's: `members_cumulative` (B-13: a members close counted
|
||||
from its count's first close, `"rounding": "cumulative_since"`),
|
||||
`account_renamed` (before the first `account.renamed`, B-31),
|
||||
`require_tax_category` (before the first `settings.set` naming
|
||||
`policy.require_tax_category`, B-32) and `party_creditors` (before the
|
||||
first `party.creditor_set`, B-35). A later piece asks the owner's
|
||||
go-ahead before the first such declaration (plan D-39).
|
||||
readable by it. A tool journaling several commands as one declares the
|
||||
feature before the first of them, never between them (a refused format
|
||||
upgrade would leave the tool's work half done): `books.set_w9` declares
|
||||
`vendor_1099_decisions` before the W-9 when the vendor's W-9 flag follows
|
||||
it. P3's: `members_cumulative` (B-13: a members close counted from its
|
||||
count's first close, `"rounding": "cumulative_since"`), `account_renamed`
|
||||
(before the first `account.renamed`, B-31), `require_tax_category`
|
||||
(before the first `settings.set` naming `policy.require_tax_category`,
|
||||
B-32), `party_creditors` (`party.creditor_set`: defect 24, B-35),
|
||||
`payment_instruments` (`instrument.added`, `entry.instrument_set`:
|
||||
defect 12, B-19) and `vendor_1099_decisions` (`vendor.1099_set` with who
|
||||
decided, a `not_reportable` decision, its reason or the date it takes
|
||||
effect, and `vendor.w9_flag_set`: defects 18 and 23, D-40, B-19). A value
|
||||
in a line of a known type that only a newer version writes (a 1099
|
||||
decision or reason kind, a payment method's kind) is newer, never
|
||||
corrupt. A later piece asks the owner's go-ahead before the first such
|
||||
declaration (plan D-39).
|
||||
|
||||
**Enforced:** `ledger_store::format` (`JournalFormat::admit`, `declared`,
|
||||
`gate`, `settle`, `declaration`), `journal::ENVELOPE_KEYS`,
|
||||
@@ -1403,8 +1565,10 @@ Existing charts are untouched: the rules are the commands', never replay's
|
||||
|
||||
A rename can still change what the books pick by name (no amount): with
|
||||
`books.cash_accounts` unset, the cash accounts are the asset accounts
|
||||
whose names say they hold cash, and the card accounts are the
|
||||
liabilities named "card" (`ledger_store::reconcilable`); the result says
|
||||
whose names say they hold cash, and, while the books record no
|
||||
business-card payment method, the card accounts are the liabilities
|
||||
named "card" but not "gift" (`ledger_core::parties::card_accounts`, B-35
|
||||
item 5); the result says
|
||||
when the new name moves the account into or out of either. It also lists
|
||||
conventions whose text names the old name. QuickBooks matches accounts
|
||||
by name, so a CPA who imported an earlier IIF is told.
|
||||
@@ -1513,13 +1677,19 @@ is the year to date, and a vendor not yet at the threshold is not yet
|
||||
reportable; a December 31 package counts the whole year, as before. The
|
||||
chart of accounts and documents/ are as they stand when the package is
|
||||
made. One list of cash accounts and one of financing accounts serve the
|
||||
whole package (the request's, else the settings'): the cash flow, the
|
||||
K-1 worksheet, the IIF's bank accounts and the 1099 payments read the
|
||||
same.
|
||||
whole package (the request's, else the settings':
|
||||
`ledger_package::Settings::with_accounts`): the cash flow, the K-1
|
||||
worksheet, the IIF's bank accounts and the 1099 payments read the same.
|
||||
So the package's 1099 worksheet is `books.vendor_1099`'s CSV for the
|
||||
same `cash_accounts`, `financing_accounts` and `through` = as_of, byte
|
||||
for byte; the tool, given no accounts, uses the settings', as a package
|
||||
given none does.
|
||||
|
||||
**Enforced:** `ledger_package::build_package` (INVARIANTS 1, 6, 7),
|
||||
`ledger_package::export_iif`, `ledger_package::vendor_1099_report` and
|
||||
`ledger_core::vendor_1099_report_with_members` (`through`).
|
||||
`ledger_package::Settings::with_accounts`, `ledger_package::export_iif`,
|
||||
`ledger_package::vendor_1099_worksheet` and `ledger_core::vendor_1099_report`
|
||||
(`through`), `books.vendor_1099` (`cash_accounts`, `financing_accounts`,
|
||||
`through`).
|
||||
**Checked:** `ledger-package` `tests/package.rs`
|
||||
(`every_file_in_an_as_of_package_stops_at_as_of`: books the same through
|
||||
as_of, with and without activity after it (a 1099 payment with its
|
||||
@@ -1529,9 +1699,11 @@ byte for byte, every file and which files there are, with and without a
|
||||
fixed asset register, mid-year and at year end; `as_of_package_iif_stops_at_as_of`,
|
||||
`the_iif_through_as_of_at_its_edges`,
|
||||
`the_1099_worksheet_stops_at_as_of`,
|
||||
`one_list_of_cash_accounts_per_package`; the property
|
||||
`one_list_of_cash_accounts_per_package`,
|
||||
`payments_to_a_vendor_come_from_the_packages_accounts`; the property
|
||||
`iif_ties_to_the_trial_balance_as_of`, 2,000 cases); `ledger-mcp`
|
||||
`oracle_mcp.rs` (`cpa_package_holds_the_year_and_its_evidence`); the
|
||||
`oracle_mcp.rs` (`cpa_package_holds_the_year_and_its_evidence`: the
|
||||
package's CSV is the tool's for the same accounts and `through`); the
|
||||
bookspec examples `bookspec/examples/as-of-package-stops-at-as-of.toml`
|
||||
and `bookspec/examples/1099-worksheet-through-as-of.toml` (`ledger-core`
|
||||
`tests/bookspec.rs`).
|
||||
@@ -1761,16 +1933,21 @@ not the books' accounting method (`books.accounting_basis`).
|
||||
`member_totals_are_the_members_equity_statement` checks every span).
|
||||
5. **Money** (P3 defect 24): the cash accounts (`[books] cash_accounts`;
|
||||
every asset account but receivables when none are set), the cards
|
||||
(liability accounts whose names say "card" but not "gift card", the
|
||||
rule the reconciliation reminders read, until payment instruments name
|
||||
them), and `[books] financing_accounts` (what the members advanced,
|
||||
loans). Every other liability (payables, the payroll withholdings, an
|
||||
(`parties::card_accounts`, the one rule the reconciliation reminders
|
||||
and the viewer read too: the liability accounts of the business-card
|
||||
payment methods the books record, B-19; while they record none, the
|
||||
liability accounts whose names say "card" but not "gift card"; never
|
||||
the account of a member's card, a member's cash or check, or a
|
||||
payment platform, which pay through the members' financing account or
|
||||
their own balance), and `[books] financing_accounts` (what the members
|
||||
advanced, loans). Every other liability (payables, the payroll withholdings, an
|
||||
accrued expense, deferred revenue, gift cards the company sold) is a
|
||||
promise: counted when it is settled, never also when it is booked
|
||||
(before P3 an accrual through any liability but payables and payroll
|
||||
counted twice). So a card account whose name doesn't say "card" is
|
||||
not money until it is listed in `financing_accounts` or an instrument
|
||||
names it, and with `financing_accounts` unset what the members
|
||||
counted twice). So, before any business card is recorded, a card
|
||||
account whose name doesn't say "card" is not money until it is listed
|
||||
in `financing_accounts` or a business-card method names it, and with
|
||||
`financing_accounts` unset what the members
|
||||
advanced is not money either: a purchase through either then counts
|
||||
for no one until it is paid off (the handbook tells the agent to list
|
||||
them).
|
||||
@@ -1819,6 +1996,38 @@ not the books' accounting method (`books.accounting_basis`).
|
||||
through the company's cash accounts, cards and financing (and, on a
|
||||
member's contribution, the K-1's cash), not the statement's ASC 230
|
||||
cash.
|
||||
9. **How party totals relate to the 1099 worksheet** (B-19; P3 defects
|
||||
12, 18, 23; D-40). They answer different questions, and neither is
|
||||
read for the other (`books.party` gives both, labelled). Party totals
|
||||
report what moved with each party, whoever handled the money; the
|
||||
1099 worksheet reports what the company, as the payor, paid a payee
|
||||
toward its information return. A member paying a contractor for the
|
||||
company through the members' financing account, the entry tagged
|
||||
with the contractor: in party totals it is paid to the contractor on
|
||||
that date, in money (the members' financing is money, item 5), and
|
||||
nothing moves with the member until the company pays them back, which
|
||||
is paid to the member. On the 1099 worksheet it is the company's
|
||||
payment to the contractor (Treas. Reg. §1.6041-1(e)(1): the member only
|
||||
writes the check at the company's direction): it counts toward the
|
||||
contractor's 1099 when it was the member's own cash, check or
|
||||
transfer, is excluded when it was a card, the member's own included
|
||||
(§1.6041-1(a)(1)(iv): Form 1099-K), and is undetermined until its
|
||||
payment method is recorded; the reimbursement pays no payee (money
|
||||
between the company's own sources). A company card's charge is paid
|
||||
in party totals and excluded on the 1099 alike. So the figures never
|
||||
contradict: over a calendar year, for a payee every entry of which
|
||||
names it alone, in books whose cash accounts are named, whose company
|
||||
cards are recorded as business-card payment methods, and that pay only
|
||||
out of cash accounts, cards and financing accounts, its party totals'
|
||||
paid less received (basis cash) is exactly its 1099 worksheet's
|
||||
`paid` + `excluded_card` + `undetermined` + `not_reportable`, less what
|
||||
the worksheet lists as money received from it for something else
|
||||
(a refund is netted on the worksheet and received in party totals).
|
||||
The bookspec example `1099-and-party-totals-for-a-members-payment`
|
||||
checks a year of it, and the property
|
||||
`party_totals_are_the_1099s_buckets` checks it over random books. A
|
||||
bill counts in neither until it is paid, and a payee's dated decision
|
||||
changes only the 1099 worksheet.
|
||||
|
||||
**Enforced:** `kernel::party_target`, `kernel::reverse_target`,
|
||||
`shares::{target, split, resolve}`, `parties::{flow, money_accounts,
|
||||
|
||||
@@ -0,0 +1,399 @@
|
||||
# Information returns: payment method, exempt payees, the payor
|
||||
Governs `form1099::vendor_1099_report`'s payment-instrument classification (card and third-party-network payments go on Form 1099-K, not 1099-NEC/MISC), its per-vendor "not reportable" reasons, and who the payor is when a member pays a company bill personally. Companion to `irs-1099-thresholds.md`.
|
||||
|
||||
## Pub. L. 119-21 (H.R. 1, July 4, 2025), §70433
|
||||
Source: <https://www.govinfo.gov/content/pkg/PLAW-119publ21/html/PLAW-119publ21.htm>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`plaw-119publ21.htm`): `84000b07c382db50ead04ce65b70983e2dcd699a931d80cd3d2edac584e9004d`
|
||||
|
||||
The `<<NOTE: ...>>` is the Government Publishing Office's margin note, as printed. Retrieved again 2026-10-21, with the same SHA-256, for subsections (a) to (e); the statute's line breaks are joined and its page marker (`[[Page 139 STAT. 244]]`, after (a)) left out; its ``…'' quotation marks are as printed.
|
||||
|
||||
**§70433 (heading)**
|
||||
|
||||
> SEC. 70433. INCREASE IN THRESHOLD FOR REQUIRING INFORMATION REPORTING WITH RESPECT TO CERTAIN PAYEES.
|
||||
|
||||
**§70433(a)**
|
||||
|
||||
> (a) In General.--Section 6041(a) is amended by striking ``$600'' and inserting ``$2,000''.
|
||||
|
||||
**§70433(b)**
|
||||
|
||||
> (b) Inflation Adjustment.--Section 6041 is amended by adding at the end the following new subsection:
|
||||
> ``(h) Inflation Adjustment.--In the case of any calendar year after 2026, the dollar amount in subsection (a) shall be increased by an amount equal to--
|
||||
> (1) such dollar amount, multiplied by
|
||||
> (2) the cost-of-living adjustment determined under section 1(f)(3) for such calendar year, determined by substituting `calendar year 2025' for `calendar year 2016' in subparagraph (A)(ii) thereof.
|
||||
>
|
||||
> If any increase under the preceding sentence is not a multiple of $100, such increase shall be rounded to the nearest multiple of $100.''.
|
||||
|
||||
**§70433(c)**
|
||||
|
||||
> (c) Application to Reporting on Remuneration for Services.--Section 6041A(a)(2) is amended by striking ``is $600 or more'' and inserting ``equals or exceeds the dollar amount in effect for such calendar year under section 6041(a)''.
|
||||
|
||||
**§70433(d)**
|
||||
|
||||
> (d) Application to Backup Withholding.--Section 3406(b)(6) is amended--
|
||||
> (1) by striking ``$600'' in subparagraph (A) and inserting ``the dollar amount in effect for such calendar year under section 6041(a)'', and
|
||||
> (2) by striking ``Only Where Aggregate for Calendar Year Is $600 or More'' in the heading and inserting ``Only Where in Excess of Threshold''.
|
||||
|
||||
**§70433(e)**
|
||||
|
||||
> (e) Conforming Amendments.--
|
||||
> (1) The heading of section 6041(a) is amended by striking ``of $600 or More'' and inserting ``Exceeding Threshold''.
|
||||
> (2) Section 6041(a) is amended by striking ``taxable year'' and inserting ``calendar year''.
|
||||
|
||||
**§70433(f)**
|
||||
|
||||
> (f) <<NOTE: 26 USC 3406 note.>> Effective Date.--The amendments made by this section shall apply with respect to payments made after December 31, 2025.
|
||||
|
||||
## Treas. Reg. §1.6041-1 (eCFR, up to date as of 2026-10-19)
|
||||
Source: <https://www.ecfr.gov/api/versioner/v1/full/2026-10-19/title-26.xml?part=1§ion=1.6041-1>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`ecfr-1.6041-1.xml`): `a27ab6bfd44679e1b68d794f0ac2e202db10df6d07e9925b6a2c069d85b58ff2`
|
||||
|
||||
**(a)(1)(i)**
|
||||
|
||||
> (a) General rule—(1) Information returns required—(i) Payments required to be reported. Except as otherwise provided in §§ 1.6041-3 and 1.6041-4, every person engaged in a trade or business shall make an information return for each calendar year with respect to payments it makes during the calendar year in the course of its trade or business to another person of fixed or determinable income described in paragraph (a)(1)(i) (A) or (B) of this section. For purposes of the regulations under this section, the person described in this paragraph (a)(1)(i) is a payor.
|
||||
|
||||
**(a)(1)(iv)**
|
||||
|
||||
> (iv) Information returns required under section 6050W for calendar years beginning after December 31, 2010. For payments made by payment card (as defined in § 1.6050W-1(b)(3)) or through a third party payment network (as defined in § 1.6050W-1(c)(3)) after December 31, 2010, that are required to be reported on an information return under section 6050W (relating to payment card and third party network transactions), the following rule applies. Transactions that are described in paragraph (a)(1)(ii) of this section that otherwise would be subject to reporting under both sections 6041 and 6050W are reported under section 6050W and not section 6041. For provisions relating to information reporting for payment card and third party network transactions, see § 1.6050W-1. Solely for purposes of this paragraph, the de minimis threshold for third party network transactions in § 1.6050W-1(c)(4) is disregarded in determining whether the transaction is subject to reporting under section 6050W.
|
||||
|
||||
**(e)(1)**
|
||||
|
||||
> (e) Payment made on behalf of another person—(1) In general. A person that makes a payment in the course of its trade or business on behalf of another person is the payor that must make a return of information under this section with respect to that payment if the payment is described in paragraph (a) of this section and, under all the facts and circumstances, that person—
|
||||
>
|
||||
> (i) Performs management or oversight functions in connection with the payment (this would exclude, for example, a person who performs mere administrative or ministerial functions such as writing checks at another's direction); or
|
||||
>
|
||||
> (ii) Has a significant economic interest in the payment (i.e., an economic interest that would be compromised if the payment were not made, such as by creation of a mechanic's lien on property to which the payment relates, or a loss of collateral).
|
||||
|
||||
**(e)(2)**
|
||||
|
||||
> (2) Determination of payor obligated to report. If two or more persons meet the requirements for making a return of information with respect to a payment, as set forth in paragraph (e)(1) of this section, the person obligated to report the payment is the person closest in the chain to the payee, unless the parties agree in writing that one of the other parties meeting the requirements set forth in paragraph (e)(1) of this section will report the payment.
|
||||
|
||||
## Treas. Reg. §1.6041-2 (eCFR, up to date as of 2026-10-19)
|
||||
Source: <https://www.ecfr.gov/api/versioner/v1/full/2026-10-19/title-26.xml?part=1§ion=1.6041-2>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`ecfr-1.6041-2.xml`): `757ff54afc739e52963c9d7d41ea71ffb5c53c37b854a214349bf86db4541551`
|
||||
|
||||
**(a)(1), first sentence**
|
||||
|
||||
> (a)(1) In general. Wages, as defined in section 3401, paid to an employee are required to be reported on Form W-2.
|
||||
|
||||
## Treas. Reg. §1.6041-3 (eCFR, up to date as of 2026-10-19)
|
||||
Source: <https://www.ecfr.gov/api/versioner/v1/full/2026-10-19/title-26.xml?part=1§ion=1.6041-3>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`ecfr-1.6041-3.xml`): `fc79d8bd578b3c152222c20a45000005354eb17bd20c4aa2f0f955020d359d7e`
|
||||
|
||||
**Introductory text**
|
||||
|
||||
> Returns of information are not required under section 6041 and §§ 1.6041-1 and 1.6041-2 for payments described in paragraphs (a) through (q) of this section. See § 1.6041-4 for reporting exemptions regarding payments to foreign persons.
|
||||
|
||||
**(c)**
|
||||
|
||||
> (c) Payments of bills for merchandise, telegrams, telephone, freight, storage, and similar charges.
|
||||
|
||||
**(p)(1) through (p)(5)**
|
||||
|
||||
> (p) Payments made to the following persons:
|
||||
>
|
||||
> (1) A corporation described in § 1.6049-4(c)(1)(ii)(A), except with respect to payments made to a corporation after December 31, 1997 for attorneys' fees, and except a corporation engaged in providing medical and health care services or engaged in the billing and collecting of payments in respect to the providing of medical and health care services. However, no reporting is required where payment is made to a hospital or extended care facility described in section 501(c)(3) which is exempt from taxation under section 501(a) or to a hospital or extended care facility owned and operated by the United States, a State, the District of Columbia, a possession of the United States, or a political subdivision, agency or instrumentality of any of the foregoing. For reporting requirements as to payments by cooperatives, and to certain other payments, see sections 6042, 6044, and 6049 and the regulations thereunder in this part.
|
||||
>
|
||||
> (2) An organization exempt from taxation under section 501(a), as described in § 1.6049-4(c)(1)(ii)(B)(1), or an individual retirement plan, as described in § 1.6049-4(c)(1)(ii)(C).
|
||||
>
|
||||
> (3) The United States, as described in § 1.6049-4(c)(1)(ii)(D).
|
||||
>
|
||||
> (4) A State, the District of Columbia, a possession of the United States, or any political subdivision of any of the foregoing, as described in § 1.6049-4(c)(1)(ii)(E).
|
||||
>
|
||||
> (5) A foreign government or political subdivision of a foreign government, as described in § 1.6049-4(c)(1)(ii)(F).
|
||||
|
||||
## Treas. Reg. §1.6041-4 (eCFR, up to date as of 2026-10-19)
|
||||
Source: <https://www.ecfr.gov/api/versioner/v1/full/2026-10-19/title-26.xml?part=1§ion=1.6041-4>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`ecfr-1.6041-4.xml`): `38ab0107a87144ae1512665cc85cbb8c35271efd9b43e8e4b898ce9c8cabc280`
|
||||
|
||||
**(a)(1), first sentence**
|
||||
|
||||
> Returns of information are not required for payments that a payor can, prior to payment, reliably associate with documentation upon which it may rely to treat as made to a foreign beneficial owner in accordance with § 1.1441-1(e)(1)(ii) or as made to a foreign payee in accordance with § 1.6049-5(d)(1) or presumed to be made to a foreign payee under § 1.6049-5(d)(2), (3), (4), or (5).
|
||||
|
||||
## Treas. Reg. §1.6049-4 (eCFR, up to date as of 2026-10-19)
|
||||
Source: <https://www.ecfr.gov/api/versioner/v1/full/2026-10-19/title-26.xml?part=1§ion=1.6049-4>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`ecfr-1.6049-4.xml`): `e37af99c7d0bdba9508d5f9033c044cc784be3761a1a504e1e5b13abb8ea9ab5`
|
||||
|
||||
**(c)(1)(ii)(A)**
|
||||
|
||||
> (A) Corporation. A corporation, as defined in section 7701(a)(3), whether domestic or foreign, is an exempt recipient. In addition, for purposes of this paragraph (c)(1), the term corporation includes a partnership all of whose members are corporations described in this paragraph (c)(1), but only if the partnership files with the payor a certificate stating that each member of the partnership meets one of the requirements of paragraph (c)(1)(ii)(A) (1) through (4) of this section. Absent actual knowledge otherwise, a payor may treat a payee as a corporation (and, therefore, as an exempt recipient) if one of the requirements of paragraph (c)(1)(ii)(A) (1), (2), (3), or (4), of this section are met before a payment is made.
|
||||
>
|
||||
> (1) The name of the payee contains an unambiguous expression of corporate status that is Incorporated, Inc., Corporation, Corp., P.C., (but not Company or Co.) or contains the term insurance company, indemnity company, reinsurance company, or assurance company, or its name indicates that it is an entity listed as a per se corporation under § 301.7701-2(b)(8)(i) of this chapter.
|
||||
>
|
||||
> (2) The payor has on file a corporate resolution or similar document clearly indicating corporate status. For this purpose, a similar document includes a copy of Form 8832, filed by the entity to elect classification as an association under § 301.7701-3(b) of this chapter.
|
||||
>
|
||||
> (3) The payor receives a Form W-9 which includes an EIN and a statement from the payee that it is a domestic corporation.
|
||||
>
|
||||
> (4) The payor receives a withholding certificate described in § 1.1441-1(e)(2)(i), that includes a certification that the person whose name is on the certificate is a foreign corporation.
|
||||
|
||||
## Treas. Reg. §1.6050W-1 (eCFR, up to date as of 2026-10-19)
|
||||
Source: <https://www.ecfr.gov/api/versioner/v1/full/2026-10-19/title-26.xml?part=1§ion=1.6050W-1>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`ecfr-1.6050W-1.xml`): `e533e6c24836a89ad117207da3dc44f0a0fc5df22a8e39cb8afd7ea8d1f1665a`
|
||||
|
||||
**(a)(5)(i)**
|
||||
|
||||
> (5) Participating payee—(i) Definition. In general, the term participating payee means any person, including any governmental unit (and any agency or instrumentality thereof), who:
|
||||
>
|
||||
> (A) In the case of a payment card transaction, accepts a payment card (as defined in paragraph (b)(3) of this section) as payment; and
|
||||
>
|
||||
> (B) In the case of a third party network transaction, accepts payment from a third party settlement organization (as defined in paragraph (c)(2) of this section) in settlement of such transaction.
|
||||
|
||||
**(b)(1)**
|
||||
|
||||
> (b) Payment card transactions—(1) Definition. The term payment card transaction means any transaction in which a payment card, or any account number or other indicia associated with a payment card, is accepted as payment.
|
||||
|
||||
**(b)(3)**
|
||||
|
||||
> (3) Payment card—(i) The term payment card means any card, including any stored-value card as defined in paragraph (b)(4) of this section, issued pursuant to an agreement or arrangement that provides for—
|
||||
>
|
||||
> (A) One or more issuers of such cards;
|
||||
>
|
||||
> (B) A network of persons unrelated to each other, and to the issuer, who agree to accept such cards as payment; and
|
||||
>
|
||||
> (C) Standards and mechanisms for settling the transactions between the merchant acquiring entities and the persons who agree to accept the cards as payment.
|
||||
>
|
||||
> (ii) Persons who agree to accept such cards as payment as described in this paragraph (b)(3) are participating payees within the meaning of paragraph (a)(5)(i)(A) of this section.
|
||||
|
||||
**(b)(4)**
|
||||
|
||||
> (4) Stored-value cards. The term stored-value card means any card with a prepaid value, including any gift card.
|
||||
|
||||
**(b)(5)(i) and (ii)**
|
||||
|
||||
> (5) Transactions for which no return of information is required under section 6050W—(i) Withdrawals and cash advances. The use of a “payment card” as defined in paragraph (b)(3) of this section by a cardholder to withdraw funds at an automated teller machine, or to obtain a cash advance or loan against the cardholder's account, is not a payment card transaction under paragraph (b)(1) of this section because the card is not being accepted as payment by a merchant or other payee.
|
||||
>
|
||||
> (ii) Convenience checks. The acceptance of a check issued in connection with a payment card account by a merchant or other payee is not a payment card transaction under paragraph (b)(1) of this section because the check is accepted and processed through the banking system in the same manner as a traditional check, not as a payment card.
|
||||
|
||||
**(c)(1)**
|
||||
|
||||
> (c) Third party network transactions—(1) Definition. The term third party network transaction means any transaction that is settled through a third party payment network.
|
||||
|
||||
**(c)(2)**
|
||||
|
||||
> (2) Third party settlement organization. The term third party settlement organization means the central organization that has the contractual obligation to make payments to participating payees (as defined in paragraph (a)(5)(i)(B) of this section) of third party network transactions. A central organization is a third party settlement organization if it provides a third party payment network (as defined in paragraph (c)(3)(i) of this section) that enables purchasers to transfer funds to providers of goods and services.
|
||||
|
||||
**(c)(3)**
|
||||
|
||||
> (3) Third party payment network. (i) The term third party payment network means any agreement or arrangement that—
|
||||
>
|
||||
> (A) Involves the establishment of accounts with a central organization by a substantial number of providers of goods or services who are unrelated to the organization and who have agreed to settle transactions for the provision of the goods or services to purchasers according to the terms of the agreement or arrangement;
|
||||
>
|
||||
> (B) Provides standards and mechanisms for settling the transactions; and
|
||||
>
|
||||
> (C) Guarantees payment to the persons providing goods or services in settlement of transactions with purchasers pursuant to the agreement or arrangement.
|
||||
>
|
||||
> (ii) A third party payment network does not include any agreement or arrangement that provides for the issuance of payment cards.
|
||||
>
|
||||
> (iii) Persons who are providers of goods and services as described in this paragraph (c)(3) are participating payees within the meaning of paragraph (a)(5)(i)(B) of this section.
|
||||
|
||||
**(c)(4)**
|
||||
|
||||
> (4) Exception for de minimis payments. A third party settlement organization is required to report any information under paragraph (a)(1) of this section with respect to third party network transactions of any participating payee only if—
|
||||
>
|
||||
> (i) The amount that would otherwise be reported under paragraph (a)(1)(ii) of this section with respect to such transactions exceeds $20,000; and
|
||||
>
|
||||
> (ii) The aggregate number of such transactions exceeds 200.
|
||||
|
||||
## Treas. Reg. §301.7701-2 (eCFR, up to date as of 2026-10-19)
|
||||
Source: <https://www.ecfr.gov/api/versioner/v1/full/2026-10-19/title-26.xml?part=301§ion=301.7701-2>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`ecfr-301.7701-2.xml`): `24815816ed81423ccb332a34a108015d0ee2f29bb1a25a743328cd9eaa313e26`
|
||||
|
||||
**(b)(1) and (2)**
|
||||
|
||||
> (b) Corporations. For federal tax purposes, the term corporation means—
|
||||
>
|
||||
> (1) A business entity organized under a Federal or State statute, or under a statute of a federally recognized Indian tribe, if the statute describes or refers to the entity as incorporated or as a corporation, body corporate, or body politic;
|
||||
>
|
||||
> (2) An association (as determined under § 301.7701-3);
|
||||
|
||||
## Treas. Reg. §301.7701-3 (eCFR, up to date as of 2026-10-19)
|
||||
Source: <https://www.ecfr.gov/api/versioner/v1/full/2026-10-19/title-26.xml?part=301§ion=301.7701-3>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`ecfr-301.7701-3.xml`): `d7fc6976edc288a34d26d458d101f707f2d0ac63820fd1c908bf5feef3fa0e56`
|
||||
|
||||
**(c)(1)(iii), first four sentences**
|
||||
|
||||
> (iii) Effective date of election. An election made under paragraph (c)(1)(i) of this section will be effective on the date specified by the entity on Form 8832 or on the date filed if no such date is specified on the election form. The effective date specified on Form 8832 can not be more than 75 days prior to the date on which the election is filed and can not be more than 12 months after the date on which the election is filed. If an election specifies an effective date more than 75 days prior to the date on which the election is filed, it will be effective 75 days prior to the date it was filed. If an election specifies an effective date more than 12 months from the date on which the election is filed, it will be effective 12 months after the date it was filed.
|
||||
|
||||
## 26 U.S.C. §6050N(a) (royalties)
|
||||
Source: <https://www.law.cornell.edu/uscode/text/26/6050N>
|
||||
Retrieved: 2026-10-21
|
||||
SHA-256 of the retrieved file (`usc6050n.html`): `becb9609580ad82de7038feb7f279551a266849d6cc48d7517b34ef7cd9c70d0`
|
||||
|
||||
**(a)**
|
||||
|
||||
> (a) Requirement of reporting Every person— (1) who makes payments of royalties (or similar amounts) aggregating $10 or more to any other person during any calendar year, or (2) who receives payments of royalties (or similar amounts) as a nominee and who makes payments aggregating $10 or more during any calendar year to any other person with respect to the royalties (or similar amounts) so received, shall make a return according to the forms or regulations prescribed by the Secretary, setting forth the aggregate amount of such payments and the name and address of the person to whom paid.
|
||||
|
||||
## Treas. Reg. §1.6045-5 (eCFR, up to date as of 2026-10-19)
|
||||
Source: <https://www.ecfr.gov/api/versioner/v1/full/2026-10-19/title-26.xml?part=1§ion=1.6045-5>
|
||||
Retrieved: 2026-10-21
|
||||
SHA-256 of the retrieved file (`ecfr-1.6045-5.xml`): `a7d4a8096c45165526d2d24785304e91a66d07be5142c81567743055a28e6d3e`
|
||||
|
||||
**(a)(1), first sentence**
|
||||
|
||||
> Except as provided in paragraph (c) of this section, every payor engaged in a trade or business who, in the course of that trade or business, makes payments aggregating $600 or more during a calendar year to an attorney in connection with legal services (whether or not the services are performed for the payor) must file an information return for such payments.
|
||||
|
||||
**(c), lead-in, and (c)(4)**
|
||||
|
||||
> (c) Exceptions. Notwithstanding paragraphs (a) and (b) of this section, a return of information is not required under section 6045(f) with respect to the following payments:
|
||||
>
|
||||
> (4) Payments made by a person to the extent that the person is required to report with respect to the same payee the payments or portions thereof under section 6041(a) and § 1.6041-1(a) (or would be required to so report the payments or portions thereof but for the dollar amount limitation contained in section 6041(a) and § 1.6041-1(a)).
|
||||
|
||||
## Instructions for Form 1099-K (Rev. December 2026)
|
||||
Source: <https://www.irs.gov/instructions/i1099k>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`i1099k.html`): `f692039fa0fd9b3a3c5224ddd0f74f5c2efec5ef7cf0dcd74727fed665a1c2f7`
|
||||
|
||||
**Specific Instructions: payment settlement entity, and Note**
|
||||
|
||||
> A PSE is a domestic or foreign entity that is a merchant acquiring entity, that is, a bank or other organization that has the contractual obligation to make payment to participating payees in settlement of payment card transactions; or a TPSO, that is, the central organization that has the contractual obligation to make payments to participating payees of third party network transactions.
|
||||
>
|
||||
> Healthcare networks, in-house accounts payable departments, and automated clearing houses do not qualify as TPSOs and do not report under section 6050W.
|
||||
|
||||
**Specific Instructions: participating payee**
|
||||
|
||||
> A participating payee is any person, including any governmental unit (and any agency or instrumentality of a governmental unit) who accepts a payment card, or any account number or other indicia associated with a payment card, as payment or accepts payment from a TPSO in settlement of a third party network transaction.
|
||||
|
||||
**Specific Instructions: payment card**
|
||||
|
||||
> A payment card is any card, including any stored-value card (having prepaid value, including gift cards), issued according to an agreement or arrangement that provides for all of the following.
|
||||
>
|
||||
> One or more issuers of the cards.
|
||||
>
|
||||
> A network of persons unrelated to each other, and to the issuer, who agree to accept the cards as payment.
|
||||
>
|
||||
> Standards and mechanisms for settling the transactions between the merchant acquiring entities and the persons who agree to accept the cards as payment.
|
||||
|
||||
**Specific Instructions: third party payment network**
|
||||
|
||||
> A third party payment network is any agreement or arrangement that provides for the following.
|
||||
>
|
||||
> The establishment of accounts with a central organization by a substantial number of providers of goods or services who are unrelated to the organization and who have agreed to settle transactions for the provision of the goods or services to purchasers according to the terms of the agreement or arrangement.
|
||||
>
|
||||
> Standards and mechanisms for settling the transactions.
|
||||
>
|
||||
> Guarantee of payment to the persons providing goods or services (participating payees) in settlement of transactions with purchasers pursuant to the agreement or arrangement.
|
||||
>
|
||||
> A third party payment network does not include any agreement or arrangement that provides for the issuance of payment cards.
|
||||
|
||||
**Reporting under sections 6041, 6041A, and 6050W**
|
||||
|
||||
> Payments made by payment card or through a third party payment network after December 31, 2010, that otherwise would be reportable under sections 6041 (payments made in the course of a trade or business to another person) or 6041A(a) (payments of remuneration for services and certain direct sales) and 6050W are reported under section 6050W and not section 6041 or 6041A. For purposes of determining whether payments are subject to reporting under section 6050W, rather than section 6041 or 6041A, the de minimis threshold, discussed later under Box 1a, is disregarded.
|
||||
|
||||
## IRS, "Understanding your Form 1099-K" (page last reviewed or updated 28-Jun-2026)
|
||||
Source: <https://www.irs.gov/businesses/understanding-your-form-1099-k>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`understanding-1099k.html`): `23f1d27b4b4a5bd103bf2468a056d291aca8b5bcfeca06d1d5272ce1f4dba86d`
|
||||
|
||||
**Introduction**
|
||||
|
||||
> Form 1099-K is a report of payments you received for goods or services during the year from:
|
||||
>
|
||||
> Credit, debit or stored value cards such as gift cards (payment cards)
|
||||
>
|
||||
> Payment apps or online marketplaces, also called third party settlement organizations or TPSOs
|
||||
|
||||
**Who gets Form 1099-K**
|
||||
|
||||
> If your customers or clients pay you directly by credit, debit or gift card, you'll get a Form 1099-K from your payment card processor no matter how many payments you got or how much they were for.
|
||||
|
||||
**Personal payments from family and friends**
|
||||
|
||||
> Money you received from friends and family as a gift or repayment for a personal expense should not be reported on a Form 1099-K. These payments aren't taxable income.
|
||||
>
|
||||
> Be sure to note these types of payments as non-business in the payment apps when possible.
|
||||
|
||||
## Instructions for Forms 1099-MISC and 1099-NEC (Rev. December 2026)
|
||||
Source: <https://www.irs.gov/instructions/i1099mec>
|
||||
Retrieved: 2026-10-20
|
||||
SHA-256 of the retrieved file (`i1099mec.html`): `2c674f7851fd137245a5a3acc8e182e2eaa11fa9f5ea09cf5c380006dd5dc5e8`
|
||||
|
||||
The Form 1099-K paragraph (under Reminders) still opens with the sentence quoted in `irs-1099-thresholds.md`, word for word (same 12/2026 revision); it is not repeated here.
|
||||
|
||||
**Form 1099-MISC: Reportable payments to corporations**
|
||||
|
||||
> The following payments made to corporations must generally be reported on Form 1099-MISC.
|
||||
>
|
||||
> Cash payments for the purchase of fish for resale reported in box 11.
|
||||
>
|
||||
> Medical and health care payments reported in box 6.
|
||||
>
|
||||
> Substitute payments in lieu of dividends or tax-exempt interest reported in box 8.
|
||||
>
|
||||
> Gross proceeds paid to an attorney reported inbox 10.
|
||||
|
||||
**Form 1099-MISC, Box 6: Medical and Health Care Payments (second paragraph)**
|
||||
|
||||
> The exemption from issuing Form 1099-MISC to a corporation does not apply to payments for medical or health care services provided by corporations, including professional corporations. However, you are not required to report payments made to a tax-exempt hospital or extended care facility or to a hospital or extended care facility owned and operated by the United States (or its territories), a state, the District of Columbia, or any of their political subdivisions, agencies, or instrumentalities.
|
||||
|
||||
**Form 1099-NEC: Reportable payments to corporations**
|
||||
|
||||
> The following payments made to corporations must generally be reported on Form 1099-NEC.
|
||||
>
|
||||
> Attorneys’ fees reported inbox 1a.
|
||||
>
|
||||
> Payments by a federal executive agency for services (vendors) reported inbox 1a.
|
||||
|
||||
**Form 1099-NEC: Payments to corporations for legal services**
|
||||
|
||||
> The exemption from reporting payments made to corporations does not apply to payments for legal services. Therefore, you must report attorneys’ fees (in box 1a of Form 1099-NEC) or gross proceeds (in box 10 of Form 1099-MISC) as described earlier to corporations that provide legal services.
|
||||
|
||||
**Form 1099-NEC: Payments made on behalf of another person**
|
||||
|
||||
> For payments reportable under section 6041, if you make a payment on behalf of another person who is the source of the funds, you may be responsible for filing Form 1099-NEC. You are the payor for information reporting purposes if you perform management or oversight functions in connection with the payment, or have a significant economic interest in the payment (such as a lien). For example, a bank that provides financing to a real estate developer for a construction project maintains an account from which it makes payments for services in connection with the project. The bank performs management and oversight functions over the payments and is responsible for filing information returns for payments of $2,000 or more paid to contractors. For more information, see Regulations section 1.6041-1(e).
|
||||
|
||||
**Form 1099-NEC: Exceptions**
|
||||
|
||||
> Some payments do not have to be reported on Form 1099-NEC, although they may be taxable to the recipient. Payments for which a Form 1099-NEC is not required include all of the following.
|
||||
>
|
||||
> Generally, payments to a corporation (including an LLC) that is treated as a C or S corporation). However, see Reportable payments to corporations , earlier.
|
||||
>
|
||||
> Payments for merchandise, telegrams, telephone, freight, storage, and similar items.
|
||||
>
|
||||
> Payments of rent to real estate agents or property managers. However, the real estate agent or property manager must use Form 1099-MISC to report the rent paid over to the property owner. See Regulations section 1.6041-3(d); Regulations section 1.6041-1(e)(5), Example 5; and, the instructions for box 1a.
|
||||
>
|
||||
> Wages, any bonuses, prizes, and awards paid to employees (report these on Form W-2).
|
||||
>
|
||||
> Military differential wage payments made to employees while they are on active duty in the U.S. Armed Forces or other uniformed services (report on Form W-2).
|
||||
>
|
||||
> Business travel allowances paid to employees (may be reportable on Form W-2).
|
||||
>
|
||||
> Cost of current life insurance protection (report on Form W-2 or Form 1099-R).
|
||||
>
|
||||
> Payments to a tax-exempt organization including tax-exempt trusts (IRAs, HSAs, Archer MSAs, Coverdell ESAs, and ABLE (529A) accounts), the United States, a state, the District of Columbia, a U.S. territory, or a foreign government.
|
||||
>
|
||||
> Compensation for injuries or sickness by the Department of Justice as a PSO disability or survivor’s benefit, or under a state program that provides benefits for surviving dependents of a PSO who has died as the direct and proximate result of a personal injury sustained in the line of duty.
|
||||
>
|
||||
> Compensation for wrongful incarceration for any criminal offense for which there was a conviction under federal or state law. See section 139F, certain amounts received by wrongfully incarcerated individuals.
|
||||
|
||||
**Form 1099-MISC: Exceptions, first item**
|
||||
|
||||
> Generally, payments to a corporation (including a limited liability company (LLC) that is treated as a C or S corporation). However, see Reportable payments to corporations , earlier.
|
||||
|
||||
## Derived (wanderbooks)
|
||||
|
||||
- **Cards and networks go on 1099-K.** A payment made by payment card or through a third party payment network that §6041 would otherwise cover is reported under §6050W on Form 1099-K, by the payment settlement entity, and not under §6041, so it does not go on Form 1099-NEC or 1099-MISC (§1.6041-1(a)(1)(iv); the 1099-K instructions extend this to §6041A). For this test the third party network de minimis of §1.6050W-1(c)(4) (more than $20,000 and more than 200 transactions) is disregarded, so the exclusion holds below it. A payment card is any card, including a stored-value card, meaning any card with a prepaid value, gift cards included (§1.6050W-1(b)(3)(i), (b)(4)). The regulation does not name credit or debit cards; the IRS page names credit, debit and stored-value cards as payment cards. The rule covers payments made after December 31, 2010.
|
||||
- **The card must be accepted by the payee.** A payment card transaction is one in which the card, or its number or other indicia, is accepted as payment (§1.6050W-1(b)(1)); the participating payee is the person who accepts the card as payment ((a)(5)(i)(A), (b)(3)(ii)). The regulation's own exclusions turn on that test: an ATM withdrawal or cash advance is not a payment card transaction because the card is not being accepted as payment by a merchant or other payee ((b)(5)(i)), and neither is a convenience check, which is processed through the banking system ((b)(5)(ii)). So a card that only funds a transfer which the payee does not accept as a card payment is not a payment card transaction with that payee. The texts do not name card-funded transfers; this rests on (b)(1), (a)(5)(i)(A) and (b)(3)(ii), with (b)(5) as the regulation's examples. If the payee instead accepts payment from a third party settlement organization, the transaction is a third party network transaction ((a)(5)(i)(B), (c)(1) to (c)(3)).
|
||||
- **ACH is not a TPSO.** Automated clearing houses do not qualify as third party settlement organizations and do not report under §6050W (1099-K instructions, Note). A plain ACH transfer (no card, no TPSO) is therefore not a §6050W transaction, and §1.6041-1(a)(1)(iv) does not take it off Form 1099-NEC/MISC.
|
||||
- **Not reportable under §6041** (§1.6041-3, introductory text): payments of bills for merchandise, telegrams, telephone, freight, storage, and similar charges ((c)); and payments to:
|
||||
- a corporation ((p)(1)), except attorneys' fees paid after December 31, 1997 and a corporation providing, or billing and collecting for, medical and health care services; even then nothing is reported for a §501(c)(3) tax-exempt hospital or extended care facility, or one owned and operated by the United States, a State, the District of Columbia, a possession, or a political subdivision, agency or instrumentality of any of them;
|
||||
- an organization exempt from tax under §501(a), or an individual retirement plan ((p)(2));
|
||||
- the United States ((p)(3));
|
||||
- a State, the District of Columbia, a possession of the United States, or a political subdivision of any of them ((p)(4));
|
||||
- a foreign government or a political subdivision of one ((p)(5));
|
||||
- a foreign payee or foreign beneficial owner, when the payor holds documentation it may rely on before paying (§1.6041-4(a)(1)).
|
||||
|
||||
Wages paid to an employee go on Form W-2 (§1.6041-2(a)(1)). The 1099-MISC/NEC instructions count an LLC treated as a C or S corporation as a corporation, and list payments to corporations that stay reportable: cash for fish bought for resale (1099-MISC box 11), medical and health care payments (box 6), substitute payments in lieu of dividends or tax-exempt interest (box 8), gross proceeds paid to an attorney (box 10), attorneys' fees (1099-NEC box 1a), and payments by a federal executive agency for services (1099-NEC box 1a).
|
||||
- **Treating a payee as a corporation.** Absent actual knowledge otherwise, a payor may treat a payee as a corporation if, before payment, its name carries Incorporated, Inc., Corporation, Corp., or P.C. (Company or Co. does not count), or the payor has a corporate resolution or similar document on file (a copy of a Form 8832 association election counts), or a Form W-9 with an EIN stating it is a domestic corporation, or a foreign-corporation withholding certificate (§1.6049-4(c)(1)(ii)(A)(1) to (4)).
|
||||
- **The payor.** The payor is the person engaged in a trade or business who makes the payment in the course of it (§1.6041-1(a)(1)(i)). A person who pays on behalf of another is the payor only if it performs management or oversight functions in connection with the payment or has a significant economic interest in it; mere administrative or ministerial functions, such as writing checks at another's direction, are not management or oversight (§1.6041-1(e)(1)(i), (ii)). If two or more qualify, the one closest in the chain to the payee reports unless they agree in writing otherwise ((e)(2)). The quoted texts do not name a member paying the company's bill from personal funds; under (e)(1) a member who only makes the payment at the company's direction is not the payor.
|
||||
- **Corporate status by election.** An entity organized under a Federal or State statute that describes it as incorporated or as a corporation is a corporation, and so is an association as determined under §301.7701-3 (§301.7701-2(b)(1), (2); see `irs-entity-classification.md`). An election on Form 8832 takes effect on the date the form specifies, or on the date filed if it specifies none; the date can be no more than 75 days before nor more than 12 months after filing, and a date outside that range is moved to the limit (§301.7701-3(c)(1)(iii)).
|
||||
- **What §70433 changed.** It raised the §6041(a) amount from $600 to $2,000 ((a)), indexed it for calendar years after 2026 in a new §6041(h), each increase rounded to the nearest $100 ((b)), made §6041A(a)(2)'s nonemployee-compensation threshold the §6041(a) amount in effect for the calendar year ((c)) and §3406(b)(6)'s backup-withholding amount the same ((d)), and made §6041(a) count by calendar year ((e)(2)). So the $2,000 holds for Form 1099-NEC (§6041A(a)(2)) and for the 1099-MISC payments reported under §6041(a) (its "rent, salaries, wages, premiums, annuities, compensations, remunerations, emoluments, or other fixed or determinable gains, profits, and income": `irs-1099-thresholds.md`) alike. It changed neither §6050N(a)'s $10 for royalties nor §1.6045-5(a)(1)'s $600 for payments to an attorney in connection with legal services (gross proceeds, 1099-MISC box 10), which leaves out what §6041(a) already reports, or would but for its dollar amount ((c)(4)): attorneys' fees for the payor's own legal work are §6041's, at its amount. The texts quoted here don't say whether payments a payee gets on both forms add up toward one threshold.
|
||||
- **Dates.** §1.6041-1(a)(1)(iv) governs payments made after December 31, 2010. The amendments of Pub. L. 119-21 §70433 (the $2,000 threshold, `irs-1099-thresholds.md`) apply to payments made after December 31, 2025 (§70433(f)).
|
||||
@@ -1286,6 +1286,88 @@ cash, in_kind) and `update_party`'s creditor_of diff; the viewer's
|
||||
`Party::tin_last4`'s `or_else` order swapped (TIN facts and W-9 facts
|
||||
never disagree, parties INVARIANT 2a, enforced on replay).
|
||||
|
||||
## P3: 1099s (defects 23, 12 and 18; 2026-10-20)
|
||||
|
||||
The 1099 decision kept as a decision (nec, misc, not_reportable with its
|
||||
reason kind and words, undetermined), with who decided and the date it
|
||||
takes effect (D-40); payment methods and the tag on each payment; one
|
||||
report for the server, the package and the viewer (rules.md B-19). No
|
||||
mutation run (D-33); the list P12 must cover is at the end.
|
||||
|
||||
| Law (rules.md B-19) | Tests |
|
||||
|---|---|
|
||||
| Undecided is not "not reportable" (defect 18) | `undecided_is_not_not_reportable` |
|
||||
| "No 1099" is a decision with who and when; "none" refused (defect 23) | `a_vendor_marked_no_1099_is_not_undecided`, `the_cutovers_reasons_are_recorded_as_given`, `set_vendor_1099_says_what_a_decision_needs` (`ledger-mcp` `spec_1099.rs`) |
|
||||
| A member's card is excluded, their check counts, unknown is undetermined (defect 12) | `a_members_personal_card_payment_is_not_a_1099_payment`, `payments_come_from_cash_and_financing_only` |
|
||||
| Card-account payments are listed, not dropped | `card_account_payments_are_listed_not_dropped` |
|
||||
| A bank payment counts unless tagged with a card (D-40) | `a_debit_card_payment_from_the_bank_is_excluded_when_tagged` |
|
||||
| A tag describes one account (review R2) | `a_tag_naming_another_account_is_undetermined` |
|
||||
| Money between the company's own sources pays no one (R1) | `paying_down_a_financing_liability_pays_no_vendor`, `paying_the_card_bill_pays_no_vendor` |
|
||||
| Unknowns never settle the status (R3) | `a_negative_unknown_keeps_a_reportable_vendor_undetermined` |
|
||||
| Money from a vendor for anything but a refund doesn't lower its 1099: a sale, its invoice paid, a disposal, a loan (R6) | `a_sale_to_a_contractor_does_not_lower_its_1099`, `money_from_a_vendor_that_is_no_refund_does_not_lower_its_1099`, unit `the_other_receipts_note_says_what_each_entry_did` (`ledger-package`) |
|
||||
| Cash accounts named, dollars (R5, R16) | `the_report_needs_the_cash_accounts_and_dollars` |
|
||||
| A shared payment splits across buckets to the cent (R12) | `a_shared_payment_splits_across_buckets_to_the_cent`, unit `a_vendor_share_splits_across_buckets_to_the_cent` |
|
||||
| Dated decisions (D-40) | `a_status_change_mid_year_applies_by_payment_date`, `an_incorporation_on_december_30_is_a_new_vendor`, `an_llc_electing_corporate_taxation_keeps_its_vendor`, `a_dated_decision_records_a_change`, `a_decision_change_names_the_payments_it_reaches`, `an_undated_old_decision_is_in_force_from_the_beginning`, `two_status_changes_in_a_year_and_a_reversal_across_them`, unit `dated_decisions_take_effect_on_their_dates` |
|
||||
| A change for a closed or due year warns (D-40, R15) | `a_change_reaching_a_filed_year_warns` (`spec_1099.rs`) |
|
||||
| The bucket table, all 16 cases; splitting and netting exact | `payment_bucket_is_the_table_in_all_16_cases`, `buckets_net_money_moved_between_the_companys_sources`, Kani `payment_bucket_is_the_table`, `payment_split_is_exact`, `net_buckets_keeps_the_total`, bridge `payment_buckets_agree` |
|
||||
| Properties | `no_instruments_no_financing_is_the_old_report` (the regression: with cash named and no methods or financing, the old figure exactly), `buckets_partition_each_payment`, `a_reversal_nets_every_bucket_to_zero`, `the_worksheet_ties_to_the_ledger` (paid + excluded + undetermined + not reportable + receipts for something else = every payment line in the year, dated decisions, sales and receipts included; the payment lists sum to their columns) |
|
||||
| Payment methods: refusals, the reversal chain | `a_payment_method_is_refused_unless_sound`, `a_payment_method_tags_the_whole_reversal_chain`, unit tests in `instruments.rs` |
|
||||
| W-9 flag kept apart from the decision (brief 1.5, R8) | `set_vendor_1099_keeps_the_w9_flag_when_omitted`, `set_w9_keeps_the_1099_decision_and_its_source`, `set_w9_declares_the_w9_flags_feature_before_its_first_line` (`spec_1099.rs`), `marking_a_w9_keeps_who_decided_the_1099` (`ledger-store` `tests/form1099.rs`) |
|
||||
| Journal: features declared once before their first line; replay and projection exact; refusals and no-ops journal nothing; newer values newer; old books as they always meant | `ledger-store` `tests/form1099.rs` (`each_feature_is_declared_once_before_its_first_line`, `decisions_and_methods_replay_and_project`, `refusals_and_no_ops_journal_nothing`, `an_unknown_1099_value_is_newer_not_corrupt`, `books_written_before_decisions_read_as_they_always_meant`), unit tests in `ledger-store` `form1099.rs`, the op model (`refused_commands_never_reach_the_journal` with `SetVendor1099`, `SetW9Flag`, `AddInstrument`, `SetEntryInstrument`; an accepted command journals or changes nothing), `books_an_earlier_version_wrote_open_to_its_figures` (fixture `p2_vendor_1099`) |
|
||||
| Records change no entry (verification 13a) | `decision_and_method_records_change_no_entry` |
|
||||
| The quieter untagged note (R7) | `the_untagged_note_counts_only_money_out` (`ledger-package`) |
|
||||
| One builder: the package CSV is the worksheet CSV for the package's accounts; README wording | `ledger-package` `tests/package.rs` (the zip's CSV equals `vendor_1099_csv` for the request's accounts, else the settings', through as_of: `payments_to_a_vendor_come_from_the_packages_accounts`, `one_list_of_cash_accounts_per_package`, `the_1099_worksheet_stops_at_as_of`; the README line pinned); over the MCP, the package's CSV is `books.vendor_1099`'s for the same `cash_accounts`, `financing_accounts` and `through` (`ledger-mcp` `oracle_mcp.rs` `cpa_package_holds_the_year_and_its_evidence`) |
|
||||
| The viewer counts as the server does (brief 1.4) | `the_viewer_counts_the_1099_as_the_server_does` (`ledger-gui` `tests/parties.rs`) |
|
||||
| End to end, restarting between steps | `payment_methods_round_trip_and_classify_payments` (`spec_1099.rs`), `mcp_vendor_1099_over_stdio`, `spec_mcp.rs` (every tool exercised and schema-checked, `books.instruments` read-only) |
|
||||
| bookspec | `bookspec/examples/1099-*.toml` |
|
||||
|
||||
**For P12 (mutation targets, none run):** `ledger-core` `form1099.rs`
|
||||
(`plan_decision`, `apply_decision`, `check_new_decision`'s decided-before
|
||||
test, `in_force`/`in_force_before` (`<` against `<=`), `vendor_1099_report`'s
|
||||
status branches (each `>=`, `<`, `max(.,0)`, `min(.,0)`), the listing
|
||||
filter, the not-reportable and undetermined routing, the R6 test
|
||||
(`< 0`, credit side, `refund_accounts` per account type), `Roles::new`
|
||||
(which methods' accounts are financing, which a card's), `split_share` (the floor corrections,
|
||||
the sign), `vendor_part`, the unresolved fallback, `decisions_during`,
|
||||
`untagged_payments` (`> 0`, each skip, each debit kind), `decision_changes`);
|
||||
`kernel.rs` (`payment_bucket`, `split_payment`, `net_buckets`);
|
||||
`instruments.rs` and `Ledger::check_add_instrument` (each refusal),
|
||||
`set_entry_instrument` (the chain), the reversal step's copy,
|
||||
`set_vendor_w9_flag`; `ledger-store` `form1099.rs` (each decode check,
|
||||
`newer_content`), `store.rs` (`ensure_feature`, `set_vendor_1099`'s
|
||||
unchanged path, `set_vendor_w9_flag`, `add_instrument`,
|
||||
`set_entry_instrument`'s no-op, the replay and projection arms,
|
||||
`sqlite_reversal_chain`); `ledger-mcp` `tools/instruments.rs`
|
||||
(`decision_in`'s refusals, `filed_year_warnings`' closed and due tests,
|
||||
`resolve_instrument`, `add_instrument`'s warnings), `server.rs`'s
|
||||
`set_vendor_1099` (the W-9-only path) and `set_w9` (the feature declared
|
||||
first, only when the flag changes); `ledger-package` `vendor_1099.rs` (the CSV columns, every note's
|
||||
guard, `may_file`, `missing_w9`'s suffix) and `package.rs` (tin_gaps, the
|
||||
README line). The viewer has no mutation job (its musts are tested).
|
||||
|
||||
## P3: parties and 1099s landed together (2026-10-21)
|
||||
|
||||
The two pieces above, stacked on the IIF, cash flow and rename pieces, and
|
||||
reconciled where they meet. Built under D-33 (no mutation run); what P12
|
||||
must cover is at the end.
|
||||
|
||||
| What | Where | Oracle |
|
||||
|---|---|---|
|
||||
| One rule for what a card is: the recorded business cards' liabilities, else (none recorded) liabilities named "card", not "gift"; never a member's card, a member's check or a platform; a debit card on the bank is none; money follows it | `ledger-core` `tests/spec_party_totals.rs` `a_card_is_a_recorded_business_card_else_a_liability_named_card` | B-35 item 5, `parties::card_accounts` INVARIANTS 1-4 |
|
||||
| Party totals and the 1099 worksheet never contradict: paid less received is the worksheet's paid + excluded_card + undetermined + not_reportable plus its other receipts, for a vendor named alone, whatever the methods, refunds and reversals | property `party_totals_are_the_1099s_buckets` (`ledger-core` `tests/form1099.rs`; `PROPTEST_CASES`, default 256; 2,000 run clean; dropping a bucket from the sum fails at once) | B-35 item 9, by hand |
|
||||
| The same, one year by hand: a member's check, a member's card, a member's payment of unknown method, a company card charge and a company check to one contractor, then the member reimbursed | `bookspec/examples/1099-and-party-totals-for-a-members-payment.toml` | B-35 item 9; Treas. Reg. §1.6041-1(e)(1), (a)(1)(iv) |
|
||||
| The CPA package's 1099 worksheet is `books.vendor_1099`'s CSV for the package's accounts (the request's, else the settings', R18) through its as_of, byte for byte; without `through` the files differ; a `through` outside the year and an unknown account are refused | `ledger-mcp` `oracle_mcp.rs` `cpa_package_holds_the_year_and_its_evidence`; `ledger-package` `tests/package.rs` `payments_to_a_vendor_come_from_the_packages_accounts`, `one_list_of_cash_accounts_per_package`, `the_1099_worksheet_stops_at_as_of` | B-33; mcp-interface.md |
|
||||
| A feature is declared before a command's first line: `books.update_party` with a field and the first creditor journals the declaration, then the field, then the creditor | `ledger-mcp` `tests/spec_party_totals.rs` `update_party_declares_the_creditor_feature_before_its_first_line` | B-27 |
|
||||
| One bookspec loader for every example, the parties' and the 1099s' with them: `setup.parties`, `setup.members` (`distributions_account`), `setup.payees` (a party's vendor record), `setup.status_changes`, `setup.instruments`, events' `parties` and `instrument`, and the queries `vendor_1099`, `k1`, `party_part`, `party_totals`, `party_tin_last4`; refused: a party or payment method not in the setup, a reversal naming parties, party totals without a basis, a 1099 line leaving a figure out, a wrong direction or status | `ledger-core` `tests/bookspec.rs` (`every_bookspec_example_holds`, `a_party_not_in_the_setup_is_refused`, `a_party_parts_direction_is_checked`, `a_reversal_naming_parties_is_refused`, `party_totals_without_a_basis_are_refused`, `a_vendor_1099_line_leaving_a_figure_out_is_refused`, `a_vendor_1099_status_is_checked`, `a_payment_method_not_in_the_setup_is_refused`) | bookspec/README.md |
|
||||
|
||||
**For P12 (mutation targets, none run, D-33):** `parties::card_accounts`
|
||||
(the recorded-cards branch, the gift and the other-instruments
|
||||
exclusions); `ledger_package::Settings::with_accounts` (each list's
|
||||
fallback); the server's `vendor_1099` (`through`'s year check, the
|
||||
unknown-code check, the accounts passed) and `update_party`'s feature
|
||||
declaration; the bookspec loader's party, payee, decision and payment
|
||||
method setup.
|
||||
|
||||
## Benchmarks (baseline 2026-10-13)
|
||||
|
||||
No budget, by decision (the owner, 2026-10-13: the books do little work
|
||||
|
||||
+27
-3
@@ -161,13 +161,18 @@ sequence of commands, of any length**:
|
||||
closed.
|
||||
- Lean `Step.frozen`, `Steps.frozen`
|
||||
14a. **How the books are kept changes no entry**: in the model, a record
|
||||
(a setting, convention, decision, open item or approval) leaves the
|
||||
(a setting, convention, decision, open item or approval; a vendor's
|
||||
1099 decision or W-9 flag, a payment method, an entry's payment-method
|
||||
tag) leaves the
|
||||
chart, every posted entry, every draft and every period exactly as they
|
||||
were, and any number of them keeps a reachable state reachable. The
|
||||
model's `record` step touches only the records by definition, so the
|
||||
proof says the model is sound, not the engine; the engine's side is
|
||||
checked by `settings_replay_is_pure`, which snapshots every figure and
|
||||
entry around each record (rules.md B-29). Settings that change how the
|
||||
entry around each record (rules.md B-29), and for the 1099 records by
|
||||
`decision_and_method_records_change_no_entry` (ledger-store
|
||||
`tests/form1099.rs`; they change the 1099 worksheet by design, never
|
||||
an entry). Settings that change how the
|
||||
same entries are presented (the fiscal year, cash flow roles, members)
|
||||
are outside this law by design. A rename (`rename_account`, P3,
|
||||
rules.md B-31) is a record too: the model's chart is `(code, type)`
|
||||
@@ -181,7 +186,8 @@ sequence of commands, of any length**:
|
||||
and model agree on every rename's refusal and nothing else moves.
|
||||
- Lean `Step.record_changes_no_figure`, `Reachable.records` (no
|
||||
axioms at all) · property `settings_replay_is_pure` ·
|
||||
`prop_rename_changes_no_figure` · model `Cmd::Rename`
|
||||
`prop_rename_changes_no_figure` · model `Cmd::Rename` · test
|
||||
`decision_and_method_records_change_no_entry`
|
||||
|
||||
### Closing
|
||||
|
||||
@@ -282,6 +288,24 @@ their numbers are assigned when P3 lands:
|
||||
`sumOver_movement_reversal` · property
|
||||
`a_reversal_is_the_exact_opposite`
|
||||
|
||||
### 1099 payments
|
||||
|
||||
21. **A payment to a vendor is split, never lost or counted twice**:
|
||||
each payment line goes in the bucket rules.md B-19's table names (its
|
||||
16 cases: with no payment method naming its account, a financing line
|
||||
never counts and a card account's line is always a card's); the
|
||||
buckets are each exactly the credits minus debits of their lines; and
|
||||
netting money moved between the company's own sources keeps the
|
||||
total, leaves no bucket opposite it, and leaves buckets of one sign
|
||||
alone.
|
||||
- Kani `payment_bucket_is_the_table`, `payment_split_is_exact`,
|
||||
`net_buckets_keeps_the_total` · bridge `payment_buckets_agree` ·
|
||||
test `payment_bucket_is_the_table_in_all_16_cases` · properties
|
||||
`buckets_partition_each_payment`,
|
||||
`no_instruments_no_financing_is_the_old_report`,
|
||||
`a_reversal_nets_every_bucket_to_zero` (ledger-core
|
||||
`tests/form1099.rs`)
|
||||
|
||||
## What the proofs found
|
||||
|
||||
The engine already had 190+ tests, property tests, mutation testing,
|
||||
|
||||
Reference in new issue
Block a user