Receipts and order allocation
Record received funds independently of order fulfillment, with explicit evidence and durable review state.
A receipt records money actually received. An order records how much of its original supply has been paid. A second receipt does not create a second sale or reopen an already fulfilled order.
The transaction reference and buyer information help an operator find related payments. They are not unique order identifiers. Matching uses the organization and original invoice or checkout session. When recovering a missing payment, explicitly select the original transaction; never create another invoice solely to record extra cash.
Record a missing historical bank transfer
Open the original transaction and choose Record another received payment. Select the receiving bank provider and enter the actual amount, stable receiving-account identity, bank statement or remittance evidence ID, actual receipt date/time and evidence notes. Acknowledge the additional payment before recording it.
The new receipt has its own transaction ID, while retaining the original order and reference. The factual received date is separate from the server's recorded date. For example, a wire received in March but discovered in August retains March as its receipt date. This does not select a tax reporting period.
The account identity and statement evidence ID identify the receipt. Repeating the same request returns the recorded receipt. Reusing that identity with a different amount, currency, original order or receipt date is rejected. After an uncertain network response, retry the unchanged request. Do not make a second identity for the same money. The form freezes the submitted facts until the response is resolved.
500 RECEIPT_READBACK_REQUIRED also means the write outcome is uncertain. Verify the recorded receipt and retain the original submission identity; a later rejection does not prove the first request failed to commit.
An account identity is not a credential. Bank receipt facts are an operator's evidenced assertion; the form does not independently verify a bank statement. Never enter passwords or API secrets in evidence fields. Missing account evidence preserves the received cash as held funds and requires review rather than automatic allocation.
Read receipt balances
The transaction list shows the actual received amount, known retained gross amount, factual receipt date and recorded date. A quiet Extra funds marker links to the receipt details. Unknown historical balances are shown as unresolved, not as zero cash.
Details separate sale allocation, held funds, customer credit, confirmed returns and write-off positions. Reservations remain subsets of those positions. The original order budget is allocated once: two valid partial receipts of 40 and 60 can pay an order of 100; a further receipt of 100 remains held. Different currencies are not added together or silently converted.
Provider expected-amount validation remains strict for each attempt. A signed, ownership-bound Stripe settlement of 40 against an attempt expecting 100 is not normal completion: independently proven cash may be preserved as held and review-required, with no paid-order transition. Legitimate attempts expecting 40 and 60 can aggregate against an invoice of 100 without relaxing validation.
An email correction within the same authoritative checkout can preserve a second receipt as held funds requiring customer-identity review. This does not change the original order, supply basis or fulfillment. The exception requires matching organization, site and currency, an existing frozen order and no stable customer-ID conflict; it does not link different checkout sessions by email or reference.
Evidence, corrections and unavailable actions
A factual received-date correction requires evidence and the current financial version. It creates an audited operation and a new pending tax-fact revision; it does not alter the original capture replay or fabricate tax dates.
The financial command API supports evidenced false-positive matching only within its guarded tenant, customer, currency, destination-version and available-balance constraints. A prior sale allocation or unsupported prior-tax treatment cannot be moved by this correction.
Service credit, applying funds to another order and write-off require an authoritative prior-tax-aware disposition workflow and currently fail closed. Eligible receipt-backed Stripe payments can initiate provider refunds through the immutable return workflow; verified external recording and dispute mutation controls remain unavailable. Generic status, amount, invoice and tax edits cannot bypass these boundaries. Existing records remain readable.
The first receipt freezes its invoice's financial basis, including when all received funds remain held. Financial invoice corrections are then unavailable through the legacy correction workflow; nonfinancial presentation corrections remain available. Capture and correction serialize so a concurrent correction cannot overwrite the basis used by a receipt.
Every receipt has an independent durable tax obligation. Capturing funds or marking the order paid is not proof that tax has been posted. An eligible receipt that alone pays its original non-invoice order can produce either a complete original-sale tax record or an explicit, authoritative no-tax outcome when tax was disabled at capture. Pending or unresolved obligations remain reporting blockers; a missing record alone is never proof of zero tax. Materialized additional-consideration records remain independent of ordinary invoice coverage, and signed correction records retain their frozen historical basis instead of using current tax settings.
New original-sale receipts retain the calculation-relevant seller settings captured with the receipt. Releasing held funds uses that same evidence. Older receipts require a frozen tax basis or settings provably dated no later than capture; otherwise they remain in review. Historical-calculation preview and confirmation can queue eligible unposted original sales, binding the job to the reviewed evidence and settings. Changed evidence requires another preview. This does not rewrite posted tax records, authoritative no-tax outcomes or issued documents, or resolve duplicate, excess, partial or reassigned receipts automatically.
When immutable receipt evidence and the frozen historical tax profile qualify exactly, the receipt-tax worker materializes the additional-consideration record asynchronously. A later committed economic return can extend that same frozen plan with a signed historical correction and an actual-return receipt document. The return keeps its actual return date and its relationship to the original receipt, tax record, document, and reporting period. Provider return success is only a payment fact; tax posting and signed-document readiness complete separately.
Use Tax Settings → Tax record maintenance → Receipt-tax recovery to preview qualified obligations before confirming materialization. Confirmation is bound to the exact clean preview. Unsupported capabilities, missing history, ambiguous roots, changed evidence, or an unready document remain explicit review work and fail closed. The Tax Records list and detail views label additional receipts and their corrections, show frozen lineage, and offer a PDF download only after the sealed current rendition and publication proof validate.
The reporting workflow does not itself file or amend a return. A historical Union OSS correction appears in a later export only after staff record evidenced filed history and explicitly authorize the frozen correction for that later quarter. New OSS receipt qualification requires schema-2 baseline evidence with the exact registration identifier covered by the qualified advice. Existing schema-1 filed history remains usable for its existing reports and corrections, but it is not rewritten or inferred from live settings. Unknown prior filed history remains unresolved; it is never replaced with a live aggregate or zero.
Receiving-account enrollment
Enroll the stable processor or receiving-bank account before creating new payment attempts. Once enrolled, the account identity is immutable on that provider configuration, including concurrent updates. Credentials may rotate without changing this identity. A different actual account requires a separate provider configuration; multiple configurations for the same actual account must use the same identity.
An existing attempt keeps its pinned account identity. Editing a current provider configuration never retrospectively identifies an older unbound attempt. Such cash remains held for evidenced review. Enrolling an account is not a migration of historical receipts.
Checkout switching
Before switching away from bank instructions, checkout asks whether the customer has already sent the transfer. If not, the customer is told not to use the previous instructions. If already sent, waiting or contacting the merchant is advised; switching requires acknowledgment of possible duplicate payment. Switching does not recall a wire or cancel a debit already submitted to its provider. Cancellation controls reflect the provider's current capability.
Issued instructions remain warning evidence after refresh, cancellation or a later attempt. The warning also applies when selecting the same bank provider could start another attempt, including a selection restored from a provider URL or checkout handoff.
Migration and operational prerequisites
Financial writes require a writable MongoDB replica set with sessions. There is no standalone-Mongo or best-effort multi-write fallback. Receipt/source uniqueness indexes are verified prerequisites. Receipt/order projections, allocations and effect intents are committed together with bounded retries.
The organization-scoped receipt backfill API previews by default. Apply in bounded batches of at most 100, retaining the returned cursor, and rerun safely when necessary. It does not merge payments by reference or copy tax documents, provider events, invoices or completed fulfillment history. Ambiguous identities, missing dates and unproven historical adjustments remain explicit review work. Proven prior fulfillment is preserved without replaying it; a refund must not reopen the original order budget.
CSV imports cannot update existing financial records or create received/refunded/disputed payments without the receipt workflow. Pending-attempt imports remain available. Capture of a valid late receipt restores visibility of an earlier soft-deleted attempt; concurrent editor/delete writes cannot hide the newly received cash.
Coordinated cutover and rollback
Deploy compatible Main Backend, Admin Backend and both frontends together. Before enabling receipt capture, verify the replica set is writable and the required receipt/source indexes exist. Stop older completion, repair and import workers before the cutover; otherwise they can bypass receipt allocation. Preview the bounded backfill first, retain its cursor and review counts, and apply only within the intended organization.
After the first receipt-backed financial write, rolling application code back to old financial writers is unsafe. Preserve the database and pending obligations, stop financial mutation workers, and roll forward with a compatible fix. Do not delete receipt/allocation collections, drop uniqueness indexes, rerun old fulfillment handlers or change factual dates to make a rollback appear successful. Resume workers only after the compatible write boundary is restored.