Accounting Office

A business owner needs to know what arrived, what is owed, what has been paid, and what the books can honestly say. An invoice in mail and a matching bank movement are evidence to connect, not a finished accounting judgment. Accounting Office would preserve that connection through review, reconciliation, and an explainable period close.

This candidate study, prepared 2026-09-11, proposes accounting.office revision 1, outside the accepted Portfolio. It supplies no source implementation, registered PatternWorkflowWorkflow, executable configuration, live mail/bank integration, or jurisdiction support claim. Workflow owns acceptance and revision law; State of Work owns delivery evidence.

Knowledge and obligations explores a proposed successor revision: source-effective rules, scoped professional answers, and entity-specific obligation instances. That proposal neither changes this revision's contract nor establishes acceptance or delivery.

One accounting lifecycle

The proposed owner is one entity's accounting lifecycle:

source evidence → proposed classification/match → validated and reviewed journal
→ reconciliation → period close → accepted scope, exact partial, unresolved, or handoff

An AccountingOfficeRequest@1 would bind the entity, period, purpose, source coverage, exact compliance profile, rule versions, reviewer authority, privacy policy, and effect ceilings. An AccountingOfficeOutcome@1 would identify accepted records and reports, exceptions, unresolved balances, missing coverage, and required handoffs. Refusal and an indeterminate external action remain explicit outcomes. A plausible report cannot substitute for missing evidence.

During a pilot, the external accountant's books remain the reference. Accounting Office shadows them, records disagreements, and prepares evidence for resolution; it cannot silently replace their books or treat agreement on one period as general accounting acceptance. Acceptance names the reviewer, scope, rule versions, exceptions, and reconciliation evidence.

Records that survive the conversation

The candidate would retain distinct, linked records for:

• Evidence: each source occurrence, custody and coverage observations, original bytes and their separate digest, extraction version, and attributed corrections. Identical bytes can arrive through several occurrences; a digest alone does not identify the business event.
• Commercial obligations: counterparty identity and evidence; invoices, accounts payable/receivable, credit notes, due dates, disputes, advance allocations, and supporting contracts.
• Money and books: bank observations, match proposals, journal entries and postings, transaction and functional currencies, FX source/date/rate, rounding, reconciliation exceptions, and period closure evidence.
• Assets and recurring rights: acquisition/disposal basis, separate book and tax schedules, impairment evidence where applicable, subscription rights, renewal dates, cancellation conditions, and future obligations.
• Compliance outputs: attributed tax positions, applicable rule versions, report and filing candidates, reviewer disposition, and separately observed submission/acceptance receipts.

These records must support calculations another reviewer can reproduce. The accounting kernel therefore uses decimal arithmetic with deterministic balancing, rounding, currency precision, effective-date resolution, and rule selection. A model can propose a classification or explanation; it cannot choose the arithmetic or establish tax law.

Before posting, validate accounts, dates, amounts, provenance, and applicable review. Once posted, a correction appends a reversal or adjustment so the original remains inspectable. A closed period stays locked. Authorized reopening records its reason and produces a successor close while preserving the predecessor.

Portable rules, isolated entities

The proposed Composition-owned EntityComplianceProfile@1 binds legal form, tax residence, functional/reporting currency, accounting period, typed registrations and their effective dates. A versioned JurisdictionPack@1 resolves accounting, company-law, income-tax, VAT/GST/withholding, and filing rules and schemas. Transaction facts and treaty overlays may change which rules apply. Provider dialect translates transport fields; it never decides law.

Neither a country string nor a successful import proves support. Missing, conflicting, expired, or inapplicable rules block the affected judgment with an exact reason. Portability requires a second wholly synthetic foreign profile with distinct rules, effective-time changes, calendar, and currency. Its fixture must demonstrate deliberate rule selection and refusal without fallback; this study makes no live foreign legal assertion.

To admit a rule, retain its authoritative source, source digest, publication and effective dates, applicability predicates, reviewer, executable revision, and expected fixtures. Research can assemble that evidence, but its findings cannot activate themselves.

When a rule changes, identify the open cases it affects and preserve earlier judgments. It cannot silently recompute a filed return or closed period. Selection must continue to distinguish interface language, bank country, tax residence, establishment, and transaction jurisdiction; none substitutes for the others.

Each entity keeps separate books, credential references, source coverage, grants, and acceptance authority. A counterparty buying services establishes a commercial relationship, not permission to operate that counterparty's books. Shared software and reusable profiles do not create shared financial authority.

Proposed Patterns and configuration

These are proposed PatternWorkflowWorkflow identities, separate from the CompositionAppApp revision:

The following is non-loadable, nonbinding design notation, not a RuneService Config FileService Config File or accepted schema. Exact registrations and deployment syntax remain future work.

composition: accounting.office / revision 1
entity_ref: synthetic-entity-a
compliance_profile: synthetic-a / revision 1
jurisdiction_pack: synthetic-rules-a / revision 1
mail: provider_ref, capability_revision, read_scope, history_coverage
bank: provider_ref, capability_revision, account_refs, read_scope
documents: intake_ref, accepted_media, quarantine_policy
effects: ingestion_policy_ref, review_policy_ref, payment_policy_ref
privacy: local_policy_ref, approved_target_refs, disclosure_budget
close: period_ref, reviewer_ref, exception_policy_ref

Intake and effects have different authority

MailAdapter, BankAdapter, and DocumentAdapter name proposed application-facing ports, not existing global LychD classes or new Core offices or Extension DomainsPlug-in AreasPlug-in Areas. Mail separates read, draft, send, and delivery observation. Bank separates read, payment preparation, submission, status observation, and reconciliation. Document intake retains original evidence and quarantines untrusted content. Any required registration must identify the receiving owner, typed Contribution, Provider, profile revision, and Registrant under Extensions; these names do not justify stuffing bank or mail operations into ToolConnector.

Before using an adapter, inspect its declared operations, coverage, limits, and recovery semantics. Unsupported operations must refuse or return a manual handoff. During intake, use cursors to track traversal while keeping document identity separate. At-least-once ingestion deduplicates repeated delivery without losing distinct arrivals. Partial imports, unavailable attachments, and historical gaps remain visible.

Classification comes after that evidence is established. Refunds, fees, FX differences, and payments without invoices each need their own evidence and judgment. A bank movement alone cannot become an automatic expense.

Bounded standing policy may authorize low-impact ingestion and repeated exact actions. Fresh consent is required when the applicable HitLApproval StepApproval Step or effect policy requires it; there is no mandatory per-click doctrine. Approval binds the exact entity, operation, recipient/account, payload, amount/currency, policy, and expiry as applicable. Mutation invalidates it. Credentials stay in their owning custody and never enter model context.

Observed submission is not delivered mail, settled money, or an accepted filing. An unclear timeout stays indeterminate. Recovery observes and reconciles the original external identity before any retry; uncertain execution cannot silently create a duplicate payment or message.

Follow an invoice through its separate acts. Preparing the document does not issue it. Issuing reserves its number within the entity's declared series and preserves that revision; a later correction links its predecessor. Sending, receiving payment, and recognizing revenue each create distinct records.

A filing candidate follows the same evidence discipline: freeze its source/period and rule/schema revisions before submission. Generation and local validation establish a candidate, while official acceptance still requires its own receipt.

Privacy before remote cognition

Here PortalCloud ModelCloud Model means remote provider cognition. The candidate follows Context and Security:

local minimization + classification + lineage
→ consumer-specific PrivacyCut + independent verification
→ Security EgressDecision for exact target, payload, purpose, and expiry
→ transmission → quarantined return → validation and local admission

Local processing removes unnecessary identities, metadata, quoted correspondence, attachment text, and embedded banking information before a remote candidate is considered. Amounts, dates, relationships, and unusual combinations can themselves identify a business. Pseudonyms, reversible identifiers, and hashes are not anonymity. Semantic abstraction must preserve the question's declared invariants; if that cannot be verified, the work remains local or refuses the remote road.

Any re-identification map remains separately controlled locally under ContextBriefing PackBriefing Pack's lease law. No map, raw history, credential, or local decision evidence accompanies the request. Related calls, retries, and derived summaries count toward cumulative disclosure. A failed local capability or privacy check creates no implicit cloud fallback. A returned recommendation remains untrusted and cannot directly post, pay, send, or file. State records that the shared privacy machinery is not delivered.

Statutory records retain their actual legally required contents. An accountant may need exact originals through a separately authorized, exact-recipient exchange; model anonymization cannot replace that channel or alter the books. Applicable Security disclosure law still governs that exchange.

A wholly synthetic advance

A fictional entity receives 2,400 currency units before providing services across two periods. The intake records the bank observation and contractual evidence separately, then proposes an advance allocation. Under an explicitly synthetic rule fixture, reviewed evidence of service completion supports allocation of 1,200 units in each period. The example asserts no real tax treatment; tax timing remains a separately resolved position.

A missing completion record leaves the affected allocation unresolved. An invoice mismatch retains both originals and the discrepancy. A cash scenario may compare retaining the remaining advance against future obligations without changing the journal. If remote reasoning is eligible, it receives only the abstract synthetic problem required for that task, never a private transaction pattern disguised by substituted names.

Foreign owners and the stopping line

Asset/subscription inventory here concerns accounting value, rights, and renewal obligations. Physical warehouse custody, stock counting, and IoT remain with their actual owner. Accounting Office consumes exact settled count/valuation evidence and records its accounting interpretation. AAn SuiteApp BundleApp Bundle becomes necessary only when a promised result must coordinate several owners' live InvocationsJob RequestsJob Requests; Choosing a Home retains that routing test.

Cash strategy and tactics produce scenarios with assumptions, liquidity constraints, and uncertainty. Any proposed Broker client handoff must fit its admitted insurance-service scope; a report provides neither trading agency nor payment authority. An external accountant or filing system remains an unmanaged external precondition unless an exact admitted integration says otherwise. No foreign reference lends credentials, lifecycle control, or settlement authority.

Fixtures that can defeat the proposal

CompositionAppApp ownership itself fails if these records, judgments, recovery, and finish already belong to an exact existing owner, or if regional variation requires incompatible lifecycles concealed in profiles. A mere report projection, provider wrapper, or ProductPackaged OfferPackaged Offer label cannot establish the proposed office. Conversely, distinct deployment credentials alone do not justify another CompositionApp.

Implementation would begin with local synthetic receipts and the deterministic accounting kernel, then an explicitly authorized read-only shadow against reference books. Accounting acceptance follows demonstrated reconciliation and reviewer judgment; optional external effects come later with their own evidence. Portfolio acceptance establishes a maintained design boundary, while executable delivery requires source contracts, focused verification, and maintained receipts. Until then this remains a candidate study.