Last reviewed: 2026-08-13 Accepted decisions: - ../decisions/accepted/0020-initial-release-scope-and-financial-workflow-taxonomy.md - ../decisions/accepted/0021-income-accounting-facts-and-templates.md - ../decisions/accepted/0029-cross-workflow-accounting-event-identity.md - ../decisions/accepted/0034-sales-tax-accounting-and-remittance-boundary.md

Sales Tax Accounting and Remittance Contract

Purpose and ownership

This contract defines the provider-agnostic initial-release boundary for:

accepting reviewed upstream sales-tax determinations;
distinguishing seller-owned from facilitator- or statutory-collector- remitted tax;
preparing Sales and Receivables accounting;
reconciling filing-summary workpapers to accepted facts and posted ledger truth;
preserving protected external-filing and external-payment completion evidence;
posting a seller-owned liability remittance through central Accounting;
linking a later non-posting bank-statement match; and
exposing exact sales-tax checks to Close.

BooksPlus owns accounting control, reconciliation, evidence linkage, protected decisions, posting coordination, and review history. The originating system, marketplace, tax provider, reviewed user source, and applicable legal or tax authority own transaction origination, taxability, sourcing, rates, calculation, statutory responsibility, filing transmission, and payment execution.

BooksPlus does not infer a legal conclusion from a provider name, marketplace label, account code, description, amount, customer location, or transaction origin. Effective-dated responsibility is reviewed input supported by active same-company evidence.

Canonical objects

SalesTaxCapabilityProfile
SalesTaxResult
SalesTaxJurisdictionSummary
SalesTaxReturnControl
SalesTaxReturnInclusion
SalesTaxReconciliationSnapshot
SalesTaxExternalFilingEvidence
SalesTaxRemittance
SalesTaxExternalPaymentEvidence
FinanceSalesTaxRemittanceMatchResult

These are workflow and control records. They are not journal entries, a tax subledger, a tax return transmitted by BooksPlus, or formal financial-report truth.

Stable values

Capability levels:

accounting_summary
filing_summary

Calculation sources:

operational_system
external_tax_provider
marketplace_facilitator
user_entered

Liability owners:

seller
marketplace_facilitator
other_statutory_collector

Compliance agents:

seller
operational_system
external_tax_provider
marketplace_facilitator

Return-control statuses:

staged
held_for_review
ready_for_approval
approved_for_external_filing
filed_externally
completed
abandoned

Remittance statuses:

prepared
approved_for_external_payment
paid_externally
posted
bank_matched
abandoned

Currentness outcomes:

current
stale_before_filing
amendment_required_after_filing

Remittance dispositions:

remittance_required
no_remittance_zero_due
no_remittance_credit_or_refund

The initial contract supports only sales_and_use_tax as the tax type. Use tax on purchases, VAT/GST, excise, payroll, income, franchise, property, and other taxes remain outside this contract.

Capability profile

A SalesTaxCapabilityProfile requires:

stable id, company id, version, and status;
source system and source-system instance when applicable;
capability level;
inclusive effective start and optional end dates;
supported calculation-source, liability-owner, and compliance-agent values;
covered registrations, agencies, jurisdictions, official jurisdiction codes, and reporting locations when filing_summary applies;
tax type and cash- or accrual-reporting basis when filing_summary applies;
active same-company Source Document evidence for responsibility, registration, marketplace certification or agreement, and source capability;
created and reviewed actor and timestamps; and
deterministic normalized meaning hash.

Profiles are versioned and append-oriented. A changed profile supersedes the prior profile without rewriting facts already accepted under it. Overlapping active profiles with ambiguous meaning are blocked. A source declaration alone does not activate a capability; BooksPlus requires reviewed evidence and exact effective-date coverage.

accounting_summary permits seller-liability posting and source-to-ledger reconciliation. It never makes a source eligible for jurisdictional return support.

filing_summary includes accounting_summary requirements and additionally permits jurisdictional return workpapers only for the exact registration, jurisdiction, period, basis, source fields, and evidence the profile covers.

Accepted SalesTaxResult

Every tax-bearing Sales and Receivables fact contains one or more SalesTaxResult components. Each component requires:

stable component id, company id, and accepted Sales fact reference;
source system, external event identity, idempotency identity, and normalized meaning hash inherited from the accepted fact;
capability-profile id and version effective for the source activity;
calculation source, liability owner, and compliance agent;
source activity date or inclusive range and posting date or target period;
company currency;
sales amount excluding tax;
seller-owned tax amount;
facilitator- or other-statutory-collector-remitted tax amount;
customer-charge control total when supplied;
seller receivable or settlement control total;
active primary Source Document and responsibility evidence;
change type and original-result relationship when applicable; and
jurisdiction summaries when filing_summary applies.

Amounts are non-negative at Money precision. One tax amount appears in exactly one ownership bucket. An amount cannot be both seller-owned liability and facilitator-remitted support.

Required equations are:

customer charge control total
= sales amount excluding tax
 + seller-owned tax amount
 + facilitator- or statutory-collector-remitted tax amount

seller receivable or settlement control total
= sales amount excluding tax
 + seller-owned tax amount

The second equation excludes facilitator- or statutory-collector-remitted tax because that amount is neither owed to the seller nor a seller liability. Source fees, commissions, reserves, chargebacks, and net marketplace deposits are separate accepted facts or evidence; they must not be netted into these equations without their owning contract.

If a source does not supply a customer-charge total, BooksPlus may derive it only as the displayed sum of the three explicit components. It must not use that derived display value as upstream tax determination.

Sales preparation and posting

For a seller-owned product or service sale:

debit receivable.trade for the seller receivable control total;
credit revenue.product or revenue.service for sales excluding tax; and
credit tax.sales_tax_payable for seller-owned tax.

For a facilitator- or other-statutory-collector-remitted product or service sale:

debit receivable.trade for sales excluding tax plus any separate seller-owned tax in the same accepted summary;
credit revenue.product or revenue.service for sales excluding tax;
credit tax.sales_tax_payable only for the separate seller-owned amount; and
preserve facilitator- or statutory-collector-remitted tax as non-ledger return-support and audit information.

The debit, credits, source control totals, ownership components, and prepared preview must reconcile exactly before readiness. A facilitator amount never creates, clears, or changes the seller's Sales Tax Payable account.

Mixed summaries are allowed only when each ownership component is explicit, supported by the same effective profile coverage, and exactly reconciled. Ambiguous, unsupported, or inferred ownership remains held. All ledger effects use the existing Summary Accounting workflow and central Accounting posting path.

Filing-summary jurisdiction data

Each SalesTaxJurisdictionSummary requires, as applicable:

stable id and parent SalesTaxResult id;
tax agency, registration, filing jurisdiction, official jurisdiction code, tax type, and filing period;
reporting location and reporting basis;
gross sales, taxable sales, nontaxable or exempt sales, and marketplace- facilitated sales;
summarized rate or versioned rate components when supplied;
seller-owned tax and facilitator- or statutory-collector-remitted tax;
adjustments, credits, and refunds with stable original relationships;
source control totals; and
active Source Document evidence.

Jurisdiction summaries reconcile exactly to their parent result. Unsupported or incomplete jurisdiction detail may still support accounting_summary when that capability's requirements pass, but it is ineligible for return support.

Transaction-level tax rows may remain in referenced source evidence. They do not become BooksPlus operational tax-subledger rows.

Return-control identity and inclusion

A SalesTaxReturnControl requires:

stable id and company id;
positive company-scoped return-control number, displayed as ST- followed by at least six digits;
tax agency, registration, jurisdiction, official jurisdiction code, tax type, filing period, reporting basis, due date, and company currency;
return-control schema and policy versions;
status and computed currentness;
request idempotency key and normalized meaning hash;
exact SalesTaxReturnInclusion children;
immutable SalesTaxReconciliationSnapshot;
primary and supporting Source Document references;
preparation, review, approval, external filing, completion, and abandonment attribution and audit references as applicable;
optional prior return-control id and amendment sequence; and
created and updated timestamps and actors.

Return-control numbers are immutable and unique within company. The internal id remains the durable persistence, replay, correction, backup, and support identity.

A return control covers exactly one company, registration, jurisdiction, tax type, and filing period. Each inclusion identifies the exact accepted SalesTaxResult, jurisdiction-summary component, Summary batch, posted Sales journal entry, and applicable posted correction entries. Inclusion is by durable identity, never by date, amount, description, provider label, or account alone.

An amendment is a new return control linked to the filed control it amends. It preserves the original facts, filing evidence, remittance, bank match, and audit history. It must not reopen or rewrite the original control.

Return-to-liability reconciliation

The immutable SalesTaxReconciliationSnapshot preserves at least:

included seller-owned tax by source result and jurisdiction;
included facilitator- or statutory-collector-remitted exclusions;
posted tax.sales_tax_payable credits from included Sales entries;
posted debit or credit effects from linked Corrections;
linked prior-period or prior-return credits explicitly accepted by this control;
return seller-owned liability;
approved remittance amount or no-remittance disposition;
Sales Tax Payable account id and relevant posted activity and balance;
every difference among source, fact, ledger, return, and remittance totals;
source and ledger fingerprints; and
evaluator version, actor, and timestamp.

Required equations are:

included seller-owned tax
+ linked posted correction credits
- linked posted correction debits
= return seller-owned liability

posted payable credits from included Sales entries
+ linked posted correction credits
- linked posted correction debits
= return seller-owned liability

return seller-owned liability
- explicitly linked posted prior credit applied
= approved remittance amount

All applicable source-to-fact, fact-to-ledger, jurisdiction-to-return, and return-to-remittance differences must be zero before approval. Facilitator- or statutory-collector-remitted tax reconciles as an exclusion and never enters the seller-liability equations.

A positive approved remittance uses remittance_required. Zero uses no_remittance_zero_due. A negative result may use no_remittance_credit_or_refund only with reviewed external disposition evidence; this contract does not post or receive a refund and does not create a credit-carryforward ledger rule. Unsupported discounts, penalties, interest, credits, refunds, or unexplained differences keep the control held.

Return lifecycle and currentness

Stage creates staged or held_for_review review state.
Exact successful validation moves the control to ready_for_approval.
Protected approval moves a current ready control to approved_for_external_filing.
Recording active same-company external filing evidence moves it to filed_externally.
A no-remittance control may move to completed after external filing.
A remittance-required control moves to completed only after its remittance has posted. A later bank match updates the linked remittance, not the immutable return reconciliation.
Reasoned abandonment may move staged, held_for_review, or ready_for_approval to abandoned.
Filed, completed, and abandoned controls are terminal and are not silently edited, deleted, or reused as another filing.

The currentness fingerprint covers the profile/version, registration and jurisdiction meaning, included facts and jurisdiction summaries, Summary and posted-entry identities, Corrections, Source Document supersession, payable account identity and relevant ledger activity, filing period, due date, reconciliation, and policy/evaluator versions.

A relevant change before external filing produces stale_before_filing and blocks filing evidence or remittance work until a new control is prepared. A relevant change after external filing produces amendment_required_after_filing; the filed control remains immutable and a new linked amendment is required. Actor, timestamps, display labels, control number, and UI state do not change normalized accounting meaning.

External filing evidence

SalesTaxExternalFilingEvidence requires:

stable id, company id, and return-control id;
active same-company Source Document id;
external filing confirmation reference;
externally filed timestamp and effective filing date;
filed amount controls and filing version when supplied;
recorded actor and timestamp; and
protected-action audit reference.

BooksPlus records evidence of an external act. It does not transmit the return, store tax-provider credentials in the control, or treat a draft export as filed evidence. Changed filing evidence supersedes through Source Documents and, when meaning changes after filing, requires an amendment control.

Remittance control and posting

A SalesTaxRemittance exists only for a positive approved remittance and requires:

stable id, company id, and return-control id;
positive company-scoped remittance number displayed as STR- followed by at least six digits;
approved amount, company currency, due date, and payment effective date when completed externally;
immutable tax.sales_tax_payable account id and reviewed bank account id;
status, command identities, normalized meaning hash, and expected version;
approval attribution, reason, step-up, and audit reference;
external-payment evidence;
posted journal-entry and posting audit references when posted;
Finance bank-match reference when matched; and
created and updated attribution and timestamps.

Lifecycle:

preparation after external filing creates prepared;
protected approval moves a current prepared remittance to approved_for_external_payment;
recording active same-company external payment evidence moves it to paid_externally;
protected central posting moves it to posted exactly once;
a later exact Finance statement match moves it to bank_matched; and
reasoned abandonment may move only prepared to abandoned.

BooksPlus never initiates the payment. paid_externally requires confirmation that the external payment completed, not merely that it was drafted, scheduled, or approved. Posting is blocked until that evidence exists and the payment effective date resolves to an eligible FinancialPeriod.

The remittance posting request:

debits the immutable account assigned tax.sales_tax_payable;
credits the reviewed same-company active direct-posting bank or cash account;
equals the approved remittance amount exactly;
uses company currency;
uses the external payment effective date as posting date;
references the SalesTaxReturnControl and active external-payment Source Document;
uses central Accounting and receives one ordinary posted journal-entry number; and
creates no other ledger effect.

Due date does not supply posting date. A payment fee, penalty, interest amount, discount, refund, foreign-currency amount, or difference from the approved remittance is held for separately accepted accounting treatment.

Finance bank match

FinanceSalesTaxRemittanceMatchResult is Banking and Finance-owned and requires:

stable id, company id, and source identity;
statement, statement-line, statement-account, and match-run identities;
statement date, amount, and company currency;
same-company posted SalesTaxRemittance and journal-entry ids;
the exact bank account credited by the remittance;
active Source Document evidence;
reviewed attribution, timestamp, and audit reference; and
exact amount, account, currency, and source reconciliation.

The only durable launch result is matched. Missing, ambiguous, wrong-company, wrong-account, wrong-currency, duplicate, or different-amount proposals remain visible and are not persisted as completed matches.

The match is support-only and non-posting. It does not create a Summary batch, accepted accounting event, posting preview, journal entry, clearing allocation, or second settlement. A relationship id is not required merely to link this Finance-owned result to the remittance; the direct remittance and journal-entry references are authoritative.

Corrections and amendments

A posted Sales entry or remittance is never silently changed.
Accounting errors use the canonical Accounting Correction workflow and link the resulting posted correction entry to the affected SalesTaxResult, return control, or remittance.
An upstream replacement, reversal, refund, or adjustment preserves stable source identity, change type, and original-result relationship.
An unfiled changed result requires a fresh return control.
A filed changed result requires a new amendment return control, even when a posted Accounting Correction has already repaired ledger truth.
Filing evidence, return-control amendment, Accounting Correction, and bank match are distinct records. None substitutes for another.
This contract does not authorize prior-period restatement, silent return replacement, automatic correction, or automatic reopen.

Close checks

The launch Close catalog adds:

Check code	Required meaning	Minimum policy and applicability
`sales_tax_accounting_reconciled`	Seller-owned tax in accepted Sales results affecting the target period reconciles exactly to posted Sales Tax Payable activity, with facilitator amounts excluded.	Non-waivable blocker when tax-bearing Sales activity affects the target period; otherwise `not_applicable`.
`sales_tax_filing_support_eligible`	Every seller-owned filing obligation due by the evaluation cutoff has complete `filing_summary` capability, registration, jurisdiction, basis, period, and active evidence.	Non-waivable blocker when the filing due date is on or before the evaluation cutoff; otherwise `not_applicable`.
`sales_tax_return_control_complete`	Every due return control is current, externally filed with active evidence, and completed or has an explicit current remittance in progress.	Non-waivable blocker when the filing due date is on or before the evaluation cutoff; otherwise `not_applicable`.
`sales_tax_remittance_control_complete`	Every approved positive remittance due by the cutoff has external-payment evidence and one posted remittance entry; zero or credit/refund dispositions have accepted evidence and no remittance posting.	Non-waivable blocker when the remittance due date is on or before the evaluation cutoff; otherwise `not_applicable`.
`sales_tax_bank_match_complete`	Every posted remittance covered by an available statement period has one exact non-posting Finance match.	Blocker waivable only under explicit close policy when the applicable statement period ends on or before the target period end; otherwise `not_applicable`.

The evaluation cutoff uses company accounting time under the Business Time Contract. A filing or remittance not yet due is not falsely marked passed; it is not_applicable with its due date visible. Check snapshots preserve exact control, fact, ledger, evidence, remittance, and bank-match references and evaluator versions.

These checks participate in the Close evaluation fingerprint. Close exposes them, their blockers, and allowed waiver state; it never calculates tax, creates a return, initiates payment, posts a remittance, creates a bank match, or changes a sales-tax control.

Reporting boundary

Formal financial reports continue to derive only from posted journal-entry lines.
Seller-owned Sales Tax Payable and posted remittances appear through their ordinary liability-account ledger effects.
Facilitator-remitted support, return controls, filing evidence, remittance workflow state, and bank matches do not add formal report amounts.
A report or Close drilldown may show these records as separately labeled support without changing a formal snapshot.
This contract does not define a tax return as a BooksPlus formal financial report or authorize tax-basis statements.

Authorization and audit

Binding protected actions:

sales_tax_return_control.stage
sales_tax_return_control.mark_ready
sales_tax_return_control.approve_filing
sales_tax_return_control.record_external_filing
sales_tax_return_control.abandon
sales_tax_remittance.approve
sales_tax_remittance.record_external_payment
sales_tax_remittance.post
sales_tax_remittance.record_bank_match
sales_tax_remittance.abandon

Requirements:

every action requires actor, company, target, correlation, authorization, and succeeded, denied, or failed audit evidence;
staging and marking ready require ordinary company-scoped authorization and no reason or step-up;
abandonment requires a nonblank reason;
filing approval and remittance approval require a nonblank reason and step-up confirmation;
recording external filing or payment requires active evidence and ordinary company-scoped authorization;
remittance posting requires a nonblank reason, step-up confirmation, its workflow authorization, and central Accounting posting authorization;
recording the bank match requires ordinary company-scoped authorization and never authorizes posting; and
remittance abandonment requires a nonblank reason and may target only a prepared remittance; and
adding actions to the registry or development/test bundle grants no production permission.

Audit events use the stable protected action, company, actor, target type and id, result, reason when required, machine identity when available, correlation id, and linked workflow status. They contain no bank credentials, payment credentials, tax-provider credentials, full account credentials, recovery material, or protected artifact bytes.

Evidence and sensitive data

Every profile, result, return control, filing record, remittance, payment record, and bank match resolves its required active same-company Source Documents.
Source Documents owns evidence identity, managed artifacts, supersession, and sensitive-artifact protection.
Superseded evidence cannot support a new approval, filing record, payment record, posting, or bank match.
Ordinary sales-tax tables, logs, audit events, support bundles, and exports must not contain passwords, API secrets, payment tokens, bank credentials, full payment-instrument data, authentication responses, or recovery secrets.
Registration and confirmation references preserve only the minimum reviewed business identifier needed for control and may reference protected evidence when the underlying artifact is sensitive.

Replay, concurrency, interruption recovery, and company isolation

Every mutating command has stable company-scoped command and request identity, normalized meaning, and expected version.
Exact replay returns the accepted object and audit/posting result without duplicating a control, number, evidence record, journal entry, or bank match.
Changed reuse conflicts and cannot overwrite accepted meaning.
One active original return control is accepted for one company, registration, jurisdiction, tax type, filing period, and return version; amendments use distinct linked identity and increasing sequence.
One return control has at most one active remittance; one remittance posts at most once and has at most one active exact bank match.
Concurrency uses expected-version and uniqueness enforcement at persistence boundaries. A losing request reloads accepted state or returns conflict.
Recovery reuses existing profile, result, control, snapshot, evidence, remittance, journal-entry, bank-match, number, and audit identities.
Every reference and repository query is company-scoped. Cross-company facts, accounts, periods, profiles, evidence, entries, controls, remittances, matches, actors, and audit links are rejected before mutation.

Backup and restore

Sales-tax profiles, results, jurisdiction summaries, return controls, inclusions, reconciliation snapshots, number sequences, filing evidence, remittances, payment evidence, Finance matches, Source Document links, currentness inputs, status history, and audit links are company-owned backup and restore state.

The persistence slice must update the Company Backup Snapshot Contract, catalog and schema versions, exact parent paths, replacement order, schema conformance checks, and capture/restore tests in the same change. Managed artifacts remain in the Source Documents evidence component and are not copied into ordinary relational rows.

Held or blocked outcomes

Visible held or blocked outcomes include:

missing, expired, ambiguous, overlapping, unsupported, or cross-company capability or responsibility profile;
missing calculation source, liability owner, compliance agent, capability, registration, jurisdiction, filing period, basis, or required evidence;
provider-inferred ownership or capability;
a tax amount assigned to more than one ownership bucket;
unsupported or unreconciled source, fact, jurisdiction, ledger, return, remittance, or bank totals;
facilitator-remitted tax routed to seller payable or receivable;
missing, superseded, ambiguous, or cross-company Source Documents;
unposted, wrong-company, wrong-account, wrong-currency, or stale included Sales or Correction entries;
accounting-only data presented as filing-ready;
stale pre-filing meaning or post-filing meaning requiring amendment;
missing approval, reason, step-up, external filing evidence, external payment evidence, or eligible payment period;
unsupported fee, penalty, interest, discount, refund receipt, credit carryforward posting, or payment difference;
duplicate or conflicting control, amendment, remittance, posting, or match;
unauthorized, denied, failed, interrupted, or concurrently changed action; and
attempted direct filing transmission, payment initiation, tax calculation, ledger mutation, or provider-specific bypass.

Held evidence creates no ready control, approval, filing completion, remittance posting, bank match, or ledger effect.

Explicitly excluded

native sales orders, invoices, credit memos, checkout, or payment processing;
nexus, registration, taxability, sourcing, boundary, rate, holiday, exemption, or legal-liability determination;
silent or automatic recomputation of upstream tax;
direct filing, tax-provider transmission, payment scheduling, or payment initiation;
provider transaction APIs and operational tax subledgers;
transaction-level return audit engines;
use tax on purchases, VAT/GST, excise, payroll, income, franchise, property, and other taxes;
penalties, interest, collection allowances, refund receipt, and credit- carryforward posting without later accepted truth;
foreign-currency tax accounting;
automatic amendments, corrections, reopen, accruals, or close-generated tax entries; and
provider-specific, Dolibarr-specific, or tax-service-specific behavior.

../accounting/summary-accounting.md
../accounting/posting-and-reversal.md
../accounting/source-documents.md
../accounting/close.md
../accounting/reporting.md
summary-accounting-batch.contract.md
banking-and-finance-summary-fact.contract.md
accounting-correction.contract.md
close-run.contract.md
reporting.contract.md
source-document.contract.md
account-role.contract.md
financial-period.contract.md
business-time.contract.md
security/role-permission-contract.md
security/audit-event-contract.md
security/backup-security-contract.md
security/company-backup-snapshot.contract.md