This is an internal working record, not an everyday instruction. It was written while the system was being rebuilt, for whoever maintains it. If you are here to do today's work, use the everyday documents instead: Procedures · Processes · Runbooks · The working day, step by step

CTC Billing, QBO, Files And Email Source Reconciliation¶

Status: P6-007 SOURCE-RECONCILED PROCESS FAMILY INPUT
Operating profile: ctc-execution
Source baseline: qa@8fbe3529792db8b6dcdc18abbea8e52ccebc68a4
Composite owner: PROC-BMS-BILLING-CLOSE-CTC
Atomic owners:
PROC-BMS-TRANSACTION-LIFECYCLE-CTC
PROC-BMS-AR-BILLING-CONFIRM-CTC
PROC-BMS-AR-QBO-DELIVERY-CTC
PROC-BMS-TRANSACTION-DOCUMENT-CTC
PROC-TMS-BOL-EMAIL-CTC
PROC-TMS-PACKING-LIST-EMAIL-CTC
Reconstruction packet: CTC_BILLING_QBO_FILES_EMAIL_CAPABILITY_REBUILD_PACKET.md
Policy decisions: CTC_BILLING_QBO_FILES_EMAIL_POLICY_DECISION_MATRIX.md
Parity/cutover: CTC_BILLING_QBO_FILES_EMAIL_PARITY_AND_CUTOVER_MATRIX.md
Diagrams: CTC_BILLING_QBO_FILES_EMAIL_SEQUENCE_DIAGRAMS.md
Operator runbook: CTC_BILLING_QBO_FILES_EMAIL_OPERATOR_RUNBOOK.md
Wiki projection: CTC_BILLING_QBO_FILES_EMAIL_WIKI_PROJECTION_PACKET.md
Effect boundary: repository documentation only; no Runtime, DB, provider, Wiki DB, deployment or Production write is authorized by this document.

1. Reconciliation Result¶

CTC Billing and document close is not one transaction and not one status. It is a composite review over six independently authoritative child processes.

source work
-> local generic AP/AR transaction
-> optional container AR confirm
-> optional QuickBooks Online delivery
-> optional stored-object and transaction-file linking
-> optional BOL email
-> optional Packing List target/part email
-> daily independent-checkpoint reconciliation

The following states must remain independent:

local transaction row exists
local transaction is reviewed/closed
container AR transaction is READY
QBO rows are SYNCING
QBO invoice is SYNCED
storage object exists
T_FILE link exists
file is readable
BOL email provider accepted
Packing List target/part provider accepted

No child status proves another child completed.

CLOSED != QBO SYNCED
READY != provider invoice created
HTTP 200 != durable local reconciliation
object uploaded != transaction linked
T_FILE row exists != object readable
email response returned != durable send ledger exists
one Packing List part sent != all targets/parts sent

2. Current Source Set¶

2.1 Generic transaction¶

app/systems/BMS/transaction/api_routes.php
app/systems/BMS/transaction/post_helper.php
app/shared/api/table_mutation_helper.php
app/shared/controller/common_post_helper.php

Current API surface:

POST|DELETE /api/bms/transactions/{trucking|transload|chassis|scale-ticket}
POST|PATCH  /api/bms/transactions/form
GET|DELETE  /api/bms/transactions/{id}
DELETE      /api/bms/transactions
PATCH       /api/bms/transactions/close
POST        /api/bms/transactions/chassis/bulk-input
POST        /api/bms/transactions/apply-final-transload

2.2 AR Billing and QBO¶

app/systems/BMS/ar-billing/api_routes.php
app/systems/BMS/ar-billing/ar_billing_helper.php
public/assets/js/modules/bms/ar-billing.js
app/utils/QuickBooksOnlineClient.php
app/platform/tenant/config_helper.php

Current API surface:

GET   /api/bms/ar-billing/options
GET   /api/bms/ar-billing/presets
POST  /api/bms/ar-billing/presets
PATCH /api/bms/ar-billing/presets/{uuid}
DELETE /api/bms/ar-billing/presets/{uuid}
GET   /api/bms/ar-billing/rates
PATCH /api/bms/ar-billing/rates/form
GET   /api/bms/ar-billing/workbench
POST  /api/bms/ar-billing/preview
POST  /api/bms/ar-billing/confirm
POST  /api/bms/ar-billing/qbo-sync

2.3 Files¶

app/shared/files/api_routes.php
app/shared/files/media_helper.php
app/shared/storage/file_storage.php
app/shared/controller/common_post_helper.php

Current API surface relevant to this family:

POST   /api/files/media/upload
POST   /api/files/media/download
GET    /api/files
POST   /api/files
PATCH  /api/files
DELETE /api/files/{id}
PATCH  /api/files/{id}
POST   /api/files/transaction-documents
POST   /api/files/batch

2.4 BOL and Packing List email¶

app/systems/TMS/transload/api_routes.php
app/systems/TMS/booking/api_routes.php
app/utils/GmailSender.php
app/shared/storage/file_storage.php

Current API surface:

POST /api/tms/transloads/{id}/bol-email
POST /api/tms/bookings/{id}/packing-list/email

2.5 Process and Wiki owners¶

docs/processes/CTC_BILLING_DOCUMENT_CLOSE_WORKFLOW.md
docs/processes/GENERIC_TRANSACTION_LIFECYCLE_WORKFLOW.md
docs/processes/AR_BILLING_INVOICE_WORKFLOW.md
docs/processes/QBO_INVOICE_DELIVERY_WORKFLOW.md
docs/processes/TRANSACTION_DOCUMENT_WORKFLOW.md
docs/processes/BOL_EMAIL_WORKFLOW.md
docs/processes/PACKING_LIST_EMAIL_WORKFLOW.md
docs/wiki/internal/PAGE_MAP.md

Current Wiki topics:

billing
ar-billing-qbo
ctc-daily
errors-recovery

3. Authority Map¶

Concern	Current authority	Important non-implication
Generic AP/AR header	`T_TRANSACTION`	Header existence does not prove reviewed close or provider delivery.
Generic AP/AR lines	`T_TRANSACTION_LIST`	Lines do not prove the header is complete or immutable.
AR Billing preset	`T_BILLING_PRESET`	Preset existence does not prove rate/source applicability for one candidate.
Container AR local invoice	`T_TRANSACTION` with `TYPE='AR'`, `BILLING_SCOPE='CONTAINER'` plus active lines	`QBO_SYNC_STATUS='READY'` means local confirm only.
QBO provider invoice	QuickBooks Online invoice	Provider existence does not prove local `SYNCED` save succeeded.
QBO local projection	`T_TRANSACTION.QBO_*`	`ERROR` or `SYNCING` does not prove provider absence.
Stored object	EFS/S3 object selected by `T_FILE.STORAGE/PATH/URL` metadata	Object existence does not prove any business link.
Transaction file link	active `T_FILE` row for `TABLE_NAME='T_TRANSACTION'` and target ID	Link existence does not prove object readability.
BOL recipient	active company email configuration for `BOL`	Recipient configuration does not prove send.
BOL email	Gmail provider message	`IS_DOC_SUBMITTED` and transaction status do not prove send.
Packing List recipient	company email configuration for `PACKING_LIST`	Recipient configuration does not prove every target/part send.
Packing List email	Gmail provider message per target and attachment part	Earlier success is not rolled back after a later failure.
Daily close	human/composite reconciliation	There is no universal stored composite status.

4. Generic Transaction Current Contract¶

4.1 Source types¶

The current generic transaction adapter creates or deletes AP/AR transactions for:

TRUCKING
TRANSLOAD
CHASSIS
SCALE_TICKET

T_TRANSACTION.RELATED_TABLE_NAME/RELATED_TABLE_ID identify current source records. Newer UUID fields are present for AR Billing and future migration but not every current generic path is proven UUID-first.

4.2 Form mutation¶

POST|PATCH /api/bms/transactions/form uses the generic table mutation helper for:

T_TRANSACTION
T_TRANSACTION_LIST

This means the current form contract is close to schema-shaped mutation rather than a bounded semantic command. The target reconstruction must define explicit create/edit/correct commands and must not port arbitrary table-column mutation into TypeScript.

4.3 Generic close¶

PATCH /api/bms/transactions/close forwards selected IDs and UI-supplied close fields to jtable_close_transaction().

Current source behavior:

normalizes selected positive transaction IDs;
removes a blank INVOICE_NUMBER instead of writing it;
normalizes the remaining update payload against current T_TRANSACTION columns;
bulk-updates the selected rows;
does not enforce a documented prior STATUS predicate;
does not enforce a QBO-state guard;
does not prove selected rows share one billing company or compatible values;
returns no per-row semantic result beyond the enclosing API response.

Therefore the current safe operator procedure is selection review plus exact per-row reread after the request.

4.4 Current completion¶

intended transaction IDs
+ intended active line rows
+ reviewed local close fields reread
= local generic transaction result

It does not mean:

paid
provider-synced
file-attached
emailed
printed

5. AR Billing Current Contract¶

5.1 Candidate/workbench identity¶

The current UI key is conceptually:

booking UUID
+ container/equipment UUID

The workbench derives candidate totals, warnings, source-transaction conflicts, billing customer and existing container AR state.

5.2 Review and preview¶

POST /api/bms/ar-billing/preview computes proposed charge lines from:

selected booking/container context;
billing preset;
source records;
current rates;
transaction types and QBO item mapping.

Preview is not durable. The server must recompute or validate authoritative source state at confirm time; a stale browser preview cannot be transaction authority.

5.3 Confirm batch¶

POST /api/bms/ar-billing/confirm wraps all supplied items in one DB transaction.

sequenceDiagram
    actor Office
    participant UI as AR Billing UI
    participant API as Confirm API
    database DB

    Office->>UI: Review selected candidate(s)
    UI->>API: Confirm items[]
    API->>DB: BEGIN
    loop each item
        API->>DB: Resolve booking/container/customer/preset/lines
        API->>DB: Insert or rewrite local container AR
    end
    alt every item succeeds
        API->>DB: COMMIT
        API-->>UI: confirmed transaction UUIDs
    else any item fails
        API->>DB: ROLLBACK all items
        API-->>UI: failure
    end

5.4 Existing row behavior¶

Existing source-specific AR transactions can block container AR creation.
Existing local container AR without QBO invoice may be rewritten.
Rewriting updates the header to current reviewed values and QBO_SYNC_STATUS='READY'.
Existing active lines are soft-deleted before new lines are inserted.
Existing SYNCED container AR is protected from overwrite.
No proven unique active booking/container AR constraint was found in the source review.
No row lock is used; concurrent confirm remains a duplicate/race risk.

5.5 Current completion¶

one intended local container AR header
+ reviewed active lines
+ QBO_SYNC_STATUS='READY'
+ exact header/line reread
= local AR confirm completed

QBO is still incomplete.

5.6 Automatic QBO handoff¶

The browser calls /api/bms/ar-billing/qbo-sync after successful local confirm when confirmed transaction UUIDs are returned. This is sequential client orchestration, not one local/provider transaction.

local confirm committed
-> browser receives UUIDs
-> browser starts QBO request

A browser/network interruption between these calls can leave a valid local READY invoice with no QBO attempt.

6. QBO Current Contract¶

6.1 Configuration¶

Current QBO configuration is loaded from tenant configuration keys including:

QUICKBOOKS_ONLINE_REALM_ID
QUICKBOOKS_ONLINE_ACCESS_TOKEN
QUICKBOOKS_ONLINE_ACCESS_TOKEN_EXPIRES_AT
QUICKBOOKS_ONLINE_REFRESH_TOKEN
QUICKBOOKS_ONLINE_REFRESH_TOKEN_EXPIRES_AT
QUICKBOOKS_ONLINE_CLIENT_ID
QUICKBOOKS_ONLINE_CLIENT_SECRET
QUICKBOOKS_ONLINE_BASE_URL
QUICKBOOKS_ONLINE_TOKEN_URL
QUICKBOOKS_ONLINE_TIMEOUT_SECONDS
QUICKBOOKS_ONLINE_MINOR_VERSION

Access-token refresh can update access and refresh tokens in tenant config. Credential/config publication remains a platform effect and is not owned by the invoice process.

6.2 Grouping¶

Request input includes transaction UUIDs and a grouping mode.

TRANSACTION/default
= one provider invoice group per transaction

INVOICE_NUMBER
= group same customer key + invoice number

At most ten groups are processed per request.

6.3 Claim and effect sequence¶

For one group:

validate eligible rows
-> generate claim token
-> conditional update READY/ERROR/not-synced rows to SYNCING
-> store claim token temporarily in QBO_ERROR
-> call QuickBooks createInvoice outside DB transaction
-> save QBO ID/doc/sync token and mark SYNCED using claim token predicate
-> or mark ERROR on handled exception

The provider call is not protected by a durable outbox or provider idempotency key.

6.4 Current state meanings¶

QBO state	Meaning
blank / `NOT_SYNCED`	legacy or not yet prepared; not provider evidence
`READY`	local AR confirm is ready for delivery
`SYNCING`	current source claimed the local row; provider result may be absent, in-flight or already committed
`SYNCED`	local QBO ID/status save completed; compare provider when correcting
`ERROR`	local error handling recorded; provider absence is not proven

6.5 Critical partial boundary¶

sequenceDiagram
    participant App as QBO Sync
    database DB
    participant QBO as QuickBooks Online

    App->>DB: Claim rows as SYNCING with token
    App->>QBO: createInvoice(payload)
    QBO-->>App: Provider invoice ID
    App->>DB: Save QBO ID and mark SYNCED using claim token
    alt local save succeeds
        DB-->>App: all rows updated
    else local save fails or response is lost
        App->>DB: attempt ERROR update where claim token still matches
        Note over DB,QBO: Provider invoice may exist while local row is ERROR/SYNCING/unknown.
    end

Current QuickBooksOnlineClient supports provider invoice creation only. It has no provider search, read, update, void/delete or idempotency-key interface.

6.6 Current completion¶

provider invoice exists with intended customer/doc number/amount
+ every local group transaction has QBO_INVOICE_ID
+ every local group transaction has QBO_SYNC_STATUS='SYNCED'
= QBO delivery reconciled

HTTP success, READY, SYNCING, or ERROR alone is not completion.

7. File Current Contract¶

7.1 Conceptual authorities¶

The current implementation uses two distinct but not fully normalized authorities:

Stored object
= EFS or S3 object

Business link
= T_FILE row pointing to TABLE_NAME + TABLE_ID

One physical path can be represented by multiple T_FILE rows.

7.2 Upload sequence¶

The UI normally performs:

POST /api/files/media/upload
-> object stored and metadata returned
-> POST /api/files/transaction-documents
-> one or more T_FILE rows registered

Object upload and DB link registration are separate effects.

7.3 Current metadata¶

Current file metadata includes or derives:

ID
UUID
CLIENT_ID
TABLE_NAME
TABLE_ID
TYPE
NAME/original filename
PATH
URL
STORAGE
SIZE
SEQUENCE
CREATED/UPDATED/DELETED lifecycle

Exact active schema must be verified before implementation or migration.

7.4 Completion¶

stored object exists
+ every intended transaction has an active T_FILE link
+ each link resolves to a readable download
= transaction document attachment completed

7.5 Partial boundaries¶

Object storage can succeed before link registration fails.
Link retry can create duplicate T_FILE rows.
Current sequence allocation can race.
A shared path can be referenced by several rows.
Storage-specific delete behavior can remove or retain the physical object differently.
There is no single transaction covering object store and MySQL.

7.6 Required conceptual target split¶

The target architecture must model, even if the first MySQL adapter still uses T_FILE:

FileObject
FileLink
FileReadability
FileRetention/Delete disposition

Deleting one business link must not silently delete an object still referenced by another active link.

8. BOL Email Current Contract¶

8.1 Trigger and sources¶

POST /api/tms/transloads/{id}/bol-email:

reads one tenant-scoped transload;
resolves the billing company's BOL recipient;
optionally renders the linked scale ticket as a temporary PDF;
reads all active T_FILE rows for T_TRANSLOAD;
materializes attachments into temporary local paths;
sends through GmailSender;
deletes temporary local files.

Subject:

{REFERENCE_NUMBER} BOL and Weight

The current admin username overrides recipients to a fixed developer email. This is current compatibility behavior, not a target role/profile policy.

8.2 Provider response¶

GmailSender returns:

Code
Message
Payload.id
Payload.threadId
Payload.labelIds

The BOL route returns the provider response to the caller but does not persist a durable business send ledger.

8.3 Completion¶

intended recipient
+ intended subject/reference
+ intended attachment set
+ provider message evidence in Gmail/Sent
= BOL email reconciled

IS_DOC_SUBMITTED, local transaction status or file attachment does not prove send.

8.4 Unknown-result boundary¶

If the API response is lost after Gmail accepts the message, current local data cannot distinguish sent from not sent. Search Gmail Sent by recipient, subject/reference and time before resend.

9. Packing List Email Current Contract¶

9.1 Trigger and targets¶

POST /api/tms/bookings/{id}/packing-list/email accepts current options including:

CUSTOMER
INSPECTOR
BOTH
weight/reference options

It rejects MK report mode for this CTC route.

9.2 Attachment-part model¶

The route builds the booking/equipment model, prepares attachments and splits them into Gmail-size batches when necessary.

For each selected target:

CUSTOMER subject = Packing List # {BOOKING_NUMBER}
INSPECTOR subject = Packing List # {INSPECTION_ID}

Multipart subjects append:

(Part X of Y)

9.3 Current sequential effect¶

sequenceDiagram
    participant API as Packing List Email
    participant Build as Report/File Builder
    participant Gmail

    API->>Build: Build body and attachment batches
    loop selected target
        loop attachment part
            API->>Gmail: Send target + subject + part
            alt success
                Gmail-->>API: success
                API->>API: append in-memory Results entry
            else failure
                Gmail-->>API: failure/timeout
                API-->>API: return failure with prior Results only
            end
        end
    end

Current returned Results identify successful target/subject/part, but the process has no durable send ledger and no API to resume one missing part. A target retry starts generated parts from the beginning.

The current admin username also overrides the recipient to a fixed developer email.

9.4 Completion¶

for every intended target
+ for every generated attachment part
+ one reconciled Gmail provider message
= Packing List email complete

One target or one part success is not full completion.

10. Composite Daily Close¶

The composite has no stored status and no direct mutation API.

10.1 Applicable-child classification¶

For each work item, Office/Billing determines which checkpoints apply:

local generic transaction;
container AR confirm;
QBO delivery;
transaction file;
BOL email;
Packing List email.

Not every item requires every child.

10.2 Daily checkpoint table¶

Checkpoint	Required identity	Verified result	Partial/blocked owner
Local transaction	transaction ID/UUID + source identity	header/lines/close fields reread	Billing owner
Local container AR	booking/container + transaction UUID	active lines and `READY`/current local state	AR Billing owner
QBO	group key + local transaction UUIDs + provider ID/doc	provider and local `SYNCED` agree	QBO reconciliation owner
File	object UUID/path + each `T_FILE` link	readable object through every intended link	File owner
BOL email	transload/reference + recipient + message/thread ID when available	Sent/provider evidence	TMS/Gmail owner
Packing email	booking + target + part number/total + message ID when available	every target/part reconciled	Booking/Gmail owner

10.3 Close/carry rule¶

An item is operationally closed only when every applicable checkpoint is either:

VERIFIED
or
CARRIED with exact current state + evidence + next owner

CARRIED is a human reconciliation disposition, not a new universal DB state.

11. Cross-Process Stable Identity¶

Boundary	Current identity	Required future durable identity
Source work → generic transaction	`RELATED_TABLE_NAME + RELATED_TABLE_ID`, partial UUID support	tenant + source type + source UUID + account + transaction UUID
Booking/container → local AR	booking UUID + container/equipment UUID + transaction UUID	tenant + billing scope + booking UUID + container UUID + active invoice version
Local AR → QBO group	transaction UUIDs + customer mapping + invoice number/group mode	QBO effect intent UUID + sorted local transaction UUID set + immutable payload hash
QBO provider → local reconciliation	provider invoice ID/doc/sync token	effect intent UUID + provider ID + attempt/reconciliation history
Object → transaction link	object path/UUID + `T_FILE.TABLE_NAME/TABLE_ID`	file-object UUID + independent file-link UUID
Transload → BOL email	transload ID/reference + recipient + subject	email intent UUID + source UUID + recipient-set hash + attachment-set hash
Booking → Packing email	booking ID + target + generated part	email batch UUID + target + part index/total + content/attachment hash

Do not use a provider subject alone as durable idempotency identity.

12. Current High-Risk Gaps¶

12.1 Generic transaction¶

schema-shaped form mutation;
close without prior-state predicate;
mixed selected-row company/value risk;
no complete synced-row edit/delete policy;
source creation idempotency varies by adapter;
timeout recovery requires manual per-ID reread.

12.2 AR Billing¶

preview is not mandatory before top-level Complete;
concurrent confirms can create duplicate active container AR rows;
no approved post-confirm correction workflow;
rewrite behavior soft-deletes old lines but does not create a distinct invoice-version entity;
automatic QBO handoff depends on the browser receiving local-confirm response.

12.3 QBO¶

no durable outbox/effect intent;
no provider idempotency key;
no provider search/reconciliation client;
QBO_ERROR temporarily stores a claim token and later an error string, mixing concerns;
stale SYNCING has no approved recovery;
provider-created/local-save-uncertain can duplicate on blind resend;
token refresh and provider effect share the request path.

12.4 Files¶

object and link lifecycle are conflated in T_FILE usage;
object upload and link registration are separate without durable intent;
shared-path reference/deletion risk;
orphan cleanup ownership is undefined;
link uniqueness and sequence concurrency are not proven;
storage namespace/tenant isolation needs Runtime evidence.

12.5 Gmail¶

no durable email intent/attempt/result ledger;
BOL provider IDs are returned but not persisted;
Packing List Results are in-memory response evidence only;
no target-part resume;
timeout requires manual Sent search;
fixed admin recipient override is username-based compatibility behavior;
recipient ownership, retention and resend authorization remain unclear.

13. Target Reconstruction Boundaries¶

flowchart LR
    UI[React Billing / Document Workspaces]
    Next[Next.js Web/API Adapters]
    LocalApp[Transaction / AR Application]
    EffectApp[Billing Effect Application]
    Policy[Billing / Group / Retry Policies]
    TxRepo[Transaction Repository]
    FileRepo[File Object + Link Repository]
    EffectRepo[Effect Intent / Attempt Repository]
    DB[(MySQL)]
    Worker[Node Worker]
    QBO[QuickBooks Online]
    Gmail[Gmail]
    Storage[Object Storage]

    UI --> Next
    Next --> LocalApp
    Next --> EffectApp
    LocalApp --> Policy
    EffectApp --> Policy
    LocalApp --> TxRepo
    EffectApp --> FileRepo
    EffectApp --> EffectRepo
    TxRepo --> DB
    FileRepo --> DB
    EffectRepo --> DB
    FileRepo --> Storage
    EffectRepo --> Worker
    Worker --> QBO
    Worker --> Gmail

React¶

Owns:

candidate/review UI;
local/provider/file/email checkpoint presentation;
per-item/per-group/per-target partial results;
loading, empty, denied, conflict and recovery states;
user confirmation and exact readback navigation.

Does not own:

invoice uniqueness;
transaction state transitions;
QBO grouping/idempotency;
object/link deletion safety;
provider retry eligibility.

Next.js¶

Owns thin authenticated adapters:

Server Component queries;
Route Handlers for shared/public API contracts;
bounded UI-local Server Actions only where appropriate;
tenant/actor context;
request/error mapping.

TypeScript application/domain¶

Owns:

semantic commands and queries;
state predicates and completion meaning;
transaction boundaries;
invoice/group/file/email identity;
duplicate/conflict/timeout/recovery rules;
effect intent creation and reconciliation.

Node worker¶

Owns durable external effect attempts:

QBO create/search/reconcile;
Gmail BOL send/search/reconcile;
Gmail Packing target-part send/search/reconcile;
deferred file cleanup/orphan reconciliation where approved.

MySQL first¶

Initial target repositories keep current MySQL source records while adding only approved effect/identity support. PostgreSQL follows React + Next.js + MySQL stabilization.

14. Required Next Decisions¶

The exact decision IDs and recommendations are in the policy matrix. The highest-priority unresolved decisions are:

Generic close allowed-field and prior-state contract.
Synced transaction edit/delete/correction ownership.
Active container AR uniqueness and invoice-version policy.
Whether preview becomes mandatory server-side or remains an operator procedure.
QBO stale SYNCING timeout and reconciliation owner.
QBO provider idempotency/search strategy.
File object/link ownership and shared-object deletion policy.
Durable email intent/attempt/result ledger and target-part resume.
Removal/replacement of username-based email override.
Daily Billing Close accountable owner, cadence and escalation.

15. Current Evidence Classification¶

Area	Current result
Process boundary	`SOURCE-RECONCILED`
Source adapter map	`SOURCE-RECONCILED`
Data/state model	`DETAILED INPUT`, exact schema reread still required
Semantic interface model	`DETAILED INPUT`, current adapter DTO parity still required
Provider/file partial boundaries	`SOURCE-RECONCILED`
Role/API negative matrix	`INCOMPLETE`
Current Wiki content	`NOT READ IN THIS DOCUMENTATION WAVE`
Target architecture	`RECONSTRUCTION INPUT`
Runtime/DB/provider tests	`NOT PERFORMED BY THIS DOCUMENTATION WAVE`
Lifecycle approval	`NOT GRANTED`
Migration readiness	below `M4`; policy, role, parity and verification remain

16. Documentation Update Triggers¶

Update this family together when any of the following changes:

transaction status, close fields or source relation;
AR candidate/preview/confirm behavior;
QBO state, grouping, credential or provider API behavior;
file object/link/upload/delete behavior;
BOL/Packing recipients, body, attachments or target-part sequence;
role/menu/API permission;
daily close procedure;
target React/Next.js/TypeScript/worker ownership;
migration wave, rollback or caller-zero disposition.

Required synchronized documents:

six atomic process contracts
billing composite
this reconciliation
policy matrix
rebuild packet
sequence catalog
operator runbook
Wiki projection
coverage matrix
P6 evidence/queue

---¶

Source: docs/processes/CTC_BILLING_QBO_FILES_EMAIL_RECONCILIATION.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.