Initiated, Accepted, Posted, Reconciled: Four Different Financial States

Method and evidence boundary: This is an authored financial-workflow control method, not accounting, tax, legal, banking, payment-network, or compliance advice. Every facility, person, vendor, account, transaction, amount, date, system, and result in the examples is fictional. An operator must have its qualified financial, legal, security, and system owners define the governing records, accounting treatment, authority, timing, evidence, segregation, and retention rules.

A facility manager clicks Submit on a refund request. The payment service accepts the request. An accounting system posts an entry. A bank statement later shows a movement. A monthly reconciliation links the records and clears the difference.

Which moment means the transaction is complete?

None of them by itself.

Each moment answers a different question. Submission proves an attempt. Provider acceptance proves a bounded system response. Posting proves a ledger action under a particular rule and period. Reconciliation proves that defined records were compared and their difference reached a governed disposition.

Self-storage operators do not need to become payment engineers or accountants to respect those boundaries. They do need an operating model that prevents a single green badge from standing in for four separate facts.

Open the full-size accessible diagram.

Governed companion package

Inspect the financial-state register and readiness gates.

These exact files contain an authored operating method and fictional records. They do not establish accounting treatment, a transaction outcome, reconciliation attestation, savings, a product or provider relationship, compliance, certification, external review, coverage, or recognition.

Download the source and limitations register ↓Download the financial-state control register ↓Download the completion readiness suite ↓Download the accessible evidence-map SVG ↓Download the evidence-map PNG ↓

Financial workflows tell the truth in plural

Most operating screens simplify. A button says Refunded. A work queue says Paid. A tenant account says Complete. An invoice view says Posted. A bank feed shows a line.

The simplification becomes dangerous when one label is copied into another system without preserving what it actually means.

Consider a fictional refund:

• the site initiates RF-F001 for USD 125.00;
• the provider accepts request prv_701 for processing;
• the provider later reports a terminal payment-flow state;
• accounting posts journal J-9004 in period 2026-08;
• the relevant bank or settlement evidence appears under reference BK-411;
• a reconciler matches the governed records and clears or explains every difference.

The IDs may be linked. The states should not be merged.

That distinction protects ordinary operations. It prevents a customer communication from promising a bank outcome when only a request exists. It prevents a ledger entry from being treated as independent cash evidence. It prevents a provider status from closing an accounting exception. It prevents a reconciliation label from hiding an unmatched or manually adjusted item.

The four-state gate

The labels are deliberately plain. An operator can map them to its actual systems only after the responsible owners approve the mapping.

1. Initiated

An authorized actor or governed automation created a transaction request.

Record:

• transaction-family ID and version;
• facility, legal-entity, customer, vendor, or account scope as permitted;
• action type and signed amount with currency;
• source document or approved reason;
• initiating actor, role, and authority reference;
• request time and idempotency key;
• intended destination;
• approval evidence when required;
• current owner of the next action.

Initiation does not prove delivery, provider acceptance, authorization by another party, movement of funds, ledger posting, settlement, bank receipt, reconciliation, or customer receipt.

A button click without a durable request ID is weak initiation evidence. A durable ID without a valid actor and approved source can still be unauthorized.

2. Accepted

The destination system or accountable receiver accepted a specific request version under a defined meaning.

Acceptance may be technical, operational, or financial. Those meanings must not share one unlabeled field.

For example, an API may accept a request for processing while the underlying transaction remains pending or requires another action. Current Stripe lifecycle documentation uses product-specific states including requires_payment_method, requires_confirmation, requires_action, processing, succeeded, and canceled. It notes that asynchronous methods can remain in processing before their outcome is known. That does not create a universal payment model, and it does not prove any relationship with modSTORAGE. It demonstrates why a system-specific accepted or processing state cannot be silently promoted into posting or reconciliation.

Record:

• destination and response ID;
• exact request ID, version, amount, and currency echoed or correlated;
• response state and its source-system definition;
• response time and source clock;
• remaining conditions or required action;
• whether the response is provisional, reversible, or terminal;
• next status source and expected update rule;
• exception owner.

An HTTP response, automatic message, portal receipt, or webhook is evidence of the thing it actually says. It is not evidence of a stronger state.

3. Posted

A governed ledger or subledger recorded an entry under a defined accounting rule and period.

Posting is not the same as initiation. It is not necessarily the same as provider success, payout, settlement, bank movement, invoice settlement, or reconciliation. A system may post an accrual, reclassification, fee, reserve, reversal, correction, or cash-related entry for different reasons and at different times.

Record:

• ledger and legal entity;
• journal, document, line, and batch identities;
• account and dimension references appropriate for governed use;
• debit and credit amounts with currency;
• posting date, accounting period, and source date;
• posting rule and rule version;
• preparer and approver where required;
• source transaction-family ID;
• reversal or correcting-entry relationship;
• posting evidence and current close state.

Current Microsoft Dynamics 365 Finance documentation gives a product-specific example of why these concepts differ. Its bank-reconciliation workflow separates statement import, validation, matching, unmatched items, posting certain new transactions, and marking a reconciliation complete. Configuration changes the flow. The documentation does not define universal accounting treatment; it shows that mature financial software can preserve distinct workflow states rather than treating every line as posted and reconciled at once.

4. Reconciled

Defined records were compared for a defined period and population, differences were identified, and each difference reached an approved disposition with evidence and ownership.

Reconciliation is not “both totals look close.” It is a controlled comparison contract.

Record:

• reconciliation ID and version;
• accounts, facilities, currencies, periods, and sources in scope;
• source extracts and immutable locators;
• opening balance, in-period activity, transfers, adjustments, and ending balance as applicable;
• matched items and match rules;
• unmatched items by reason, age, amount, consequence, and owner;
• manual matches and adjustments with authority;
• cutoff and timing differences;
• reversals, disputes, fees, netting, or batch relationships;
• preparer, reviewer, completion time, and reopen rule;
• final status: reconciled, reconciled_with_open_items, blocked, superseded, or reopened.

The Bureau of the Fiscal Service reconciliation guidance is written for federal Fund Balance with Treasury work, not private self-storage accounting. Within that boundary, it gives a useful control lesson: compare transaction logs with independent support, list unmatched items, preserve causes, resolve discrepancies, and do not create unsupported entries merely to force agreement.

The 2025 GAO Green Book is also a federal internal-control framework, effective beginning in fiscal year 2026. It describes management's role in designing internal control for operations, reporting, and compliance and includes preventive and detective control examples. Nonfederal organizations may adopt the framework, but it does not prescribe this method or an operator's accounting treatment. The bounded takeaway is that reliable reporting depends on designed control activities and evidence, not a reassuring interface color.

Add the states that your risk requires

The four-state gate is a minimum lens, not a universal state machine.

Depending on the transaction, the governed workflow may also need:

• drafted before authority exists;
• approved before initiation;
• delivered before receiver handling;
• authorized before capture or release;
• processing while an outcome is nonterminal;
• settled under an exact network or provider definition;
• available under an exact balance definition;
• paid_out under a payout identity;
• received_at_bank under independent bank evidence;
• matched before the reconciliation as a whole closes;
• disputed, returned, reversed, or refunded as linked events;
• written_off only under qualified authority and policy;
• unknown when the authoritative source cannot be read.

Do not add states merely to make a diagram impressive. Add a state when it changes what an operator may say, do, release, recognize, close, or escalate.

One transaction family, several source records

The operating model needs a stable transaction-family identity that links records without pretending they are one object.

transaction_family_id: TF-FICTION-0042
  initiation: request RF-F001 v2
  provider: response prv_701 and later events
  ledger: journal J-9004 lines 12-13
  settlement_or_payout: batch PB-81 when applicable
  bank: statement line BK-411
  reconciliation: REC-2026-08-07 item 44
  adjustments: none or separately identified records

The family is a correlation device. It does not erase source ownership. The provider governs its status definitions. The ledger governs posted entries. The bank or independent statement governs its line. The reconciliation record governs the comparison and disposition.

The pinned W3C PROV-O Recommendation defines general concepts for entities, activities, agents, generation, use, derivation, association, attribution, and delegation. Those concepts can describe which record was generated by which activity and linked to which actor. Provenance still does not prove authority, transaction validity, ledger correctness, settlement, or reconciliation. It makes the evidence chain inspectable; qualified controls decide what that chain means.

Amount identity is more than a number

“125” is not a financial identity.

At minimum, bind every amount to:

• signed value;
• currency;
• amount type: gross, net, tax, fee, reserve, discount, refund, payout, or another governed class;
• scale and rounding rule;
• source record and line;
• facility and legal-entity scope;
• event and accounting dates;
• transaction-family ID;
• status under the source's vocabulary.

A USD 125.00 refund request should not be matched to a USD 125.00 bank debit by amount alone. The same amount can occur many times. Match rules should use the strongest available identity and preserve whether the match was deterministic, rule-based, or manually approved.

Net amounts create another trap. A payout may combine collections, refunds, disputes, fees, reserves, timing differences, and adjustments. Current Stripe reporting guidance describes product-specific balance and payout-reconciliation reports that group transactions differently and use different relevant dates. The page notes that a payout report can help reconcile a batch after it settles, while a balance report answers a different account-activity question. That does not tell an operator how to account for anything. It shows why one payout amount cannot safely stand in for every underlying transaction state.

Reversals do not delete history

A reversal is a new governed event linked to the record it offsets or changes. It should not overwrite the original as if it never happened.

Preserve:

• original identity, state, amount, and evidence;
• reversal or correction identity;
• reason and authority;
• effective and recorded times;
• affected provider, ledger, bank, and reconciliation records;
• any remaining open item;
• corrected customer or vendor communication state;
• whether the prior reconciliation must reopen.

The same rule applies to retries. An idempotency key can prevent a duplicate request in one system, but it does not prove that every downstream system applied the same duplicate rule. A retry should return the prior bounded disposition when appropriate or create a separately linked attempt. It should never create an indistinguishable second financial event.

The owner of each next action

Every state has an owner. Those owners can differ.

• Site or central operations may own source-document completeness.
• A configured integration may own delivery monitoring.
• A processor queue may own provider exception handling.
• Accounting may own posting or exception classification.
• Treasury or a qualified financial owner may own bank evidence and settlement interpretation.
• A reconciler may own matching and difference disposition.
• A reviewer may own approval to close or reopen.

“Finance” is not enough if no accountable queue, scope, response rule, and escalation owner exist. “The system” is not enough if its failure path returns no one to the record.

Segregation requirements should be defined by qualified owners. The method does not assume that every transaction needs different people at every stage. It does require the workflow to reveal when the same actor initiated, approved, posted, matched, adjusted, and closed a consequential item so the governing policy can evaluate that fact.

What AI can safely do

An AI assistant can help assemble financial workflow evidence. It may:

• extract candidate IDs, amounts, currencies, dates, and status phrases;
• compare a source record with structured fields;
• flag a provider receipt that was labeled reconciled;
• identify a ledger line without a transaction-family link;
• propose candidate matches with cited evidence;
• group unmatched items by reason and age;
• draft an exception summary;
• detect missing review or reversal links.

It should not:

• create transaction authority;
• infer bank receipt from provider success;
• decide accounting treatment;
• invent a match from amount and date similarity;
• clear an unexplained difference;
• change a closed period;
• communicate a financial result without approved source evidence;
• promote unknown into success because a status check failed.

For consequential work, AI should remain a candidate evidence assembler. A deterministic control or qualified human applies the governing decision.

A fictional daily review

At fictional Harbor Annex, an operator reviews four transaction families.

TF-F001 — refund request<br> Initiated with approved source evidence. Provider status is processing. No ledger or bank evidence exists yet. Current label: accepted_processing; next owner: provider-exception monitor. The customer communication may state that the request was submitted and is processing only if approved policy permits that wording.

TF-F002 — vendor payment<br> The accounting system posted journal J-F002. The independent bank feed has no corresponding line inside the current cutoff. Current label: posted_unmatched; next owner: reconciler. The item is not relabeled paid merely because the ledger contains an entry.

TF-F003 — automatic payout batch<br> The payout record and bank deposit share a strong reference. Two underlying adjustments remain unclassified. Current label: bank_received_reconciliation_open; next owner: accounting exception queue. The deposit does not close the underlying classification work.

TF-F004 — duplicate request attempt<br> The retry reused the same idempotency key and returned the prior provider response. No second ledger or bank record exists. Current label: duplicate_attempt_same_disposition; next owner: workflow monitor. The audit history preserves both attempts without counting two transactions.

No case proves a real product behavior or company result. The exercise shows how a four-state gate prevents premature closure.

Metrics that do not flatten the workflow

Useful measures include:

• initiated requests without bounded acceptance;
• accepted or processing items without a next-check rule;
• provider-terminal items without governed posting disposition;
• posted items without independent match evidence;
• bank lines without transaction-family correlation;
• reconciliations closed with open items, by reason and consequence;
• manual matches by rule, reviewer, and later reopen rate;
• reversals without original-record links;
• duplicate attempts by idempotency outcome;
• unknown-source states by age and owner;
• AI-proposed matches changed or rejected by reviewers.

Every rate needs a numerator, denominator, population, period, source, exclusions, and limitations. A “reconciliation rate” is not meaningful if the denominator mixes pending, ineligible, canceled, reversed, outside-period, and unclassified items.

Do not reward a team for forcing differences to zero. A visible, owned exception can be more truthful than an unsupported adjustment.

The operator exercise

Choose one recurring financial workflow: a refund, vendor payment, automatic collection, deposit, payout, fee, or another approved transaction class.

Sample ten transaction families and answer:

1. What proves initiation and authority?
2. What exact system accepted what exact version?
3. What remaining conditions existed after acceptance?
4. What ledger or subledger record was posted, under which period and rule?
5. What independent source supports movement or receipt when relevant?
6. What match rule linked the records?
7. Which items remain unmatched or disputed?
8. Who owns every next action?
9. What reversal, retry, reopening, and correction paths exist?
10. What can the operation truthfully communicate at each state?

Classify evidence as present, missing, ambiguous, contradictory, or not_applicable. Classify state as initiated, accepted_nonterminal, accepted_terminal, posted, matched, reconciled, reconciled_with_open_items, reversed, reopened, or unknown only after the responsible owner approves the vocabulary.

Use the companion financial-state control register and 36-scenario readiness suite to test ordinary, delayed, duplicated, reversed, netted, unmatched, inaccessible-source, and AI-assisted cases. The financial-state evidence map gives teams a visual prompt for keeping authority, provider, ledger, independent-source, exception, and AI roles separate. The tools are fictional teaching records and require qualified adaptation.

Four states, four questions

Initiated asks: Was an authorized request created?

Accepted asks: What did the receiver agree to process or do?

Posted asks: What did the governed ledger record, under which rule and period?

Reconciled asks: Which independent records were compared, and what happened to every difference?

When an operator keeps those questions separate, a financial workflow can be observed without exaggerating what any one system knows.

Sources

The package-level source register preserves publication or version dates, exact claim support, retrieval time, and limitations for every external source used below.

• How Payment Intents and Setup Intents work, Stripe official product documentation, current page checked August 22, 2026.
• How to select a report, Stripe official product documentation, current page checked August 22, 2026.
• Reconciliation Procedures, Bureau of the Fiscal Service, last updated January 31, 2023.
• The Green Book, U.S. Government Accountability Office, 2025 edition effective beginning fiscal year 2026.
• Reconcile bank statements by using advanced bank reconciliation, Microsoft Learn, current page checked August 22, 2026.
• PROV-O: The PROV Ontology, W3C Recommendation, April 30, 2013.