ometere123/the-skills-bible/accounting-reconciliation-engineer

Accounting and Reconciliation Engineer

Purpose

Prove that operational events, ledgers, partners, bank statements, and accounting reports agree or have owned explainable differences.

Use this skill when

• Financial systems disagree.
• Period close requires manual spreadsheets.
• Partner settlements and ledger postings need matching.

Do not use this skill as the primary workflow when

• The task is ledger transaction design only.
• No monetary records are involved.
• Professional accounting judgement is requested without qualified review.

Required inputs

• Operational records and ledger.
• Provider and bank statements.
• Chart of accounts and periods.
• Matching identifiers and tolerances.
• Close, audit, and reporting requirements.

Classify missing information as blocking, important, or optional. Inspect the actual policies, contracts, domain models, workflows, records, integrations, data, permissions, incidents, reports, operational procedures, and regulatory constraints before asking for information that can be verified directly.

Core operating principles

• Model the domain's authoritative entities, states, invariants, actors, and evidence before selecting technology.
• Separate legal, policy, commercial, operational, and technical rules so each can change under accountable ownership.
• Treat money, identity, safety, entitlement, inventory, consent, and irreversible actions as high-integrity state.
• Use explicit state machines, idempotency, audit trails, reconciliation, and exception handling for consequential workflows.
• Preserve tenant, customer, patient, citizen, partner, and operator boundaries throughout data and action paths.
• Design for real-world delay, duplication, dispute, correction, cancellation, partial completion, and external-system failure.
• Keep generated recommendations and probabilistic scores separate from authoritative decisions and records.
• Minimise sensitive data and apply purpose, retention, access, and deletion controls across primary and derived copies.
• Make operational outcomes observable through stable identifiers, timelines, ownership, and evidence.
• Validate domain behaviour with qualified stakeholders, representative scenarios, historical failures, and safe recovery exercises.

Workflow

1. Define populations

• Identify expected records, sources, cut-offs, currencies, entities, and accounting periods.

2. Normalise source data

• Preserve raw statements while converting identifiers, amounts, dates, signs, and fees into comparable fields.

3. Design matching

• Use exact, composite, grouped, temporal, and tolerance-based rules with deterministic precedence.

4. Classify differences

• Separate timing, missing, duplicate, amount, fee, currency, status, ownership, and source-quality differences.

5. Use suspense

• Hold unresolved value in controlled accounts or queues with owner and age.

6. Design adjustments

• Require evidence, approval, reason, period, and balanced postings for corrections.

7. Design period close

• Set cut-offs, completeness checks, reconciliations, approvals, lock, late-entry, and reopen procedures.

8. Export accounting

• Map subledger activity to general-ledger accounts, entities, cost centres, and journal batches.

9. Produce evidence

• Retain source files, match decisions, exceptions, approvals, journals, and report lineage.

10. Validate

• Test duplicate statements, late settlement, partial fees, foreign exchange, reversals, and reopened periods.

Decision rules

Required outputs

• Reconciliation populations.
• Normalised source model.
• Matching and difference rules.
• Suspense and adjustment controls.
• Close and accounting export.
• Audit evidence and tests.

Domain-system quality gates

• Domain gate: Core entities, terminology, state transitions, and authoritative sources are agreed.
• Invariant gate: Money, safety, identity, entitlement, inventory, and policy invariants are enforceable.
• Authority gate: Every decision and state change has a trusted actor, permission, and accountable owner.
• Evidence gate: Consequential outcomes retain provenance, timestamps, reasons, and supporting records.
• Exception gate: Disputes, reversals, corrections, manual review, and partial failure have explicit paths.
• Privacy gate: Sensitive data is purpose-bound, minimised, access-controlled, retained, and deleted appropriately.
• Interoperability gate: External identifiers, schemas, versions, and reconciliation rules are documented and tested.
• Operational gate: Monitoring, support, incident response, recovery, and business continuity are ready.
• Fairness gate: Policies and automation are reviewed for unjustified exclusion, unequal burden, and appeal access.
• Lifecycle gate: Onboarding, change, migration, deprecation, offboarding, archival, and retirement are governed.

Evidence standard

For consequential domain conclusions, identify the exact policy, contract, jurisdiction or operating context, actor, system version, record, event time, effective time, external reference, and source evidence. Distinguish authoritative fact, derived calculation, policy interpretation, probabilistic assessment, and unresolved dispute. Do not claim legal, clinical, financial, or safety correctness from software behaviour alone.

Failure handling and escalation

Pause or escalate when:

• The authoritative rule, source of truth, accountable owner, or affected party is unclear.
• Money, inventory, identity, entitlement, clinical, public-safety, or legal state may be corrupted.
• An automated decision could materially disadvantage a person without review, explanation, or appeal.
• External systems disagree and reconciliation cannot establish authoritative state.
• Required consent, licence, contract, credential, or jurisdictional authority cannot be verified.
• Production testing could create real charges, orders, messages, appointments, claims, or public records.
• Residual financial, legal, safety, privacy, or operational risk exceeds delegated authority.

Report the exact blocker, verified state, affected parties, evidence, safe options, and smallest required decision.

Common anti-patterns

• Total-only reconciliation.
• Manual overwrite of mismatches.
• Suspense with no ageing.
• Bank statement discarded after import.
• Close completed despite unexplained material difference.

Completion checklist

• [ ] Every population has expected completeness.
• [ ] Matches are reproducible.
• [ ] Exceptions have owner and age.
• [ ] Adjustments are approved and balanced.
• [ ] Reports trace to sources.

Domain implementation record

# Domain Implementation Record
 
## Outcome
[Business, public-service, clinical, operational, or user outcome]
 
## Domain scope
[Actors, entities, jurisdictions, policies, environments, and exclusions]
 
## Authoritative state
[Systems of record, ownership, identifiers, and effective-time rules]
 
## Workflow
[States, transitions, approvals, exceptions, reversals, and deadlines]
 
## Invariants
[Money, safety, identity, entitlement, inventory, privacy, and fairness]
 
## Integrations
[Partners, protocols, schemas, credentials, delivery, and reconciliation]
 
## Evidence and audit
[Events, records, reasons, provenance, access, and retention]
 
## Validation
[Scenarios, qualified review, historical cases, recovery, and residual gaps]
 
## Operations
[Monitoring, support, incident response, continuity, and manual fallback]
 
## Lifecycle
[Change, migration, offboarding, archival, deletion, and retirement]

Related skills

• payments-ledger-engineer
• financial-systems-architect
• data-synchronization-engineer
• audit-trail-engineer

Maintenance rules

Review this skill when domain policy, law, regulation, contracts, market structure, clinical guidance, operating practice, partner interfaces, or user populations change; incidents reveal a missing invariant; the workflow becomes tied to one vendor; the file approaches 500 lines; or reusable state models, calculators, validators, or reconciliation tools would improve execution.