Accounting

Scope

Accounting is where Keystone has to prove it can carry commercial activity into durable financial truth. This guide keeps the operator-focused workflow coverage while leaving private reference detail out.

Chart of accounts, journal entries, general ledger, budgets, financial statements, LLC members, monthly/year-end close processes, purchase orders, goods receipts, three-way matching, exchange rates, bank feeds, bank reconciliation, AR management, fixed assets, obligations, annual package, tax brackets, quarterly taxes, and tax reporting/filing.

The Journal Entries table shows the persisted debit and credit totals for every entry. After posting a balanced entry, both totals must remain equal and must reflect the amount entered. The Annual Package workspace labels generation, freshness, export, and filing controls in operator language rather than translation keys.

The Financial Statements workspace keeps entity/date-scoped reports and exports together with fiscal-period operations. Run close routes an open period into the controlled Close Runs workflow; reopening requires a reason and preserves invalidation evidence for prior close packages.

Accounting: Chart of Accounts

The Chart of Accounts (COA) is the foundation of the general ledger. Keystone ships with a default COA that includes standard accounts for a small business.

Account Types

Type	Normal Balance	Examples
asset	debit	Cash, AR, Equipment
liability	credit	AP, Loans, Sales Tax Payable
equity	credit	Owner’s Capital, Retained Earnings
revenue	credit	Service Revenue, Product Sales
expense	debit	Rent, Utilities, Salaries

List Accounts

Annual Package generation failures remain visible below the generation controls with the backend’s business reason and a retry action. The page does not return to an unchanged empty state after a failed request.

Tree View

Returns accounts in a hierarchical tree structure with parent-child relationships.

Get Account with Balance

Returns account details plus current balance. Supports as_of_date query parameter (YYYY-MM-DD format) for historical balance lookups.

Create Account

Fields:

• account_number (required) – must be unique
• name (required)
• description
• normal_balance – auto-derived from account_type if not specified
• tax_category – for tax deduction mapping
• sort_order

User-created accounts are never marked as system accounts.

Update Account

Deactivate Account

Soft-deletes (deactivates) the account. Fails if:

• The account is a system account
• The account has a non-zero balance (transfer the balance first)

Journal Entries

Journal entries are the core of double-entry bookkeeping. Every financial transaction in Keystone creates journal entries.

Keystone assigns JE-000001 style entry numbers atomically. Imports and seed advances the allocator when those rows are inserted, so the next automatic posting cannot reuse an imported number. Non-numeric legacy labels do not affect the allocator. Entry-number uniqueness remains enforced within each tenant.

Types of Journal Entries

Type	Source
manual	Created by user via API
auto_invoice_sent	Invoice sent to customer
auto_invoice_paid	Invoice payment received
auto_invoice_voided	Invoice voided
auto_payment	Payment recorded
auto_credit	Credit issued
auto_refund	Refund processed
auto_expense	Expense approved/paid
auto_bill	Bill approved/paid
closing	Year-end closing entry
reversing	Reversal of another entry

List Journal Entries

Returns paginated response with items array and total count.

Get Journal Entry Detail

so browser back/forward and copied links reopen the same entity-scoped detail. Detail debit and credit totals come from the server response. When the entry has a supported source, Open source uses the server’s typed source link. A denied or unavailable source stays non-navigable and shows the server recovery guidance instead of guessing a destination.

Supported source links retain the journal entry’s company scope. A payment opens the exact payment evidence in Finance, a bank-reconciliation source opens the exact reconciliation session, and a sales-tax remittance opens the exact entity and filing year. If a credit source says Unavailable, review the customer credit register from Finance; Keystone does not advertise a record link that it cannot resolve authoritatively. Retrying a failed focused load keeps the last evidence for that same record visible, while changing the URL or entity discards stale evidence from the prior scope.

Automated payment, credit-application, bad-debt, and capital-expense depreciation journals open the invoice or expense that owns the persisted source evidence. Other automated sources may show Unavailable even when the record still exists. This means Keystone verified the source in the journal’s company but the owning workspace does not yet provide a stable record URL. For year-end close and tax journals that explicitly say the source ID is missing, use the company, fiscal period, journal description, and audit history to review the posting; do not infer an ID from the journal number.

Create Manual Journal Entry

Fields:

• entry_date (required) – must fall in an open fiscal period
• description (required)
• lines (required, at least 2):
• description
• debit_cents – exactly one of debit/credit must be non-zero per line
• credit_cents

Validation rules:

• Total debits must equal total credits
• Each line must have exactly one non-zero side (debit or credit, not both)
• The fiscal period for the entry date must exist and be open
• A counterparty, when supplied, must be a different active legal entity in the current tenant. Foreign, inactive, or self-selected entities are rejected.

The routed Journal Entries workspace resolves one active legal entity, displays that posting company before entry, scopes the list and period lookup to it, and sends the same entity on creation. Amount fields store integer cents and display the entity’s active default-profile functional currency. If that authority is missing, the form stays blocked and directs the operator to Company Profile; it does not assume USD. GL accounts are searchable by number or name. If the selected month is missing or not open, submission is blocked with a link to create, manage, or reopen that entity’s fiscal period. If the server rejects a stale period check, the error and recovery action remain visible in the open modal and all entered lines and amounts are preserved. Select Retry after the fiscal-period dependency has changed. The modal keeps that posting conflict active until it receives refreshed period authority; editing a memo or amount is not evidence that the period opened.

Each line may optionally select an accessible counterparty entity for intercompany evidence. The selector is populated only from the workspace’s validated entity directory and excludes the posting company. If that directory cannot be verified, the form shows the unavailable reason and a retry action; it does not infer an entity or claim that no counterparties exist.

The routed form assigns one request key to the open draft and blocks a second in-flight submit. Retrying that same preserved draft is safe: Keystone returns the original entry if the first request already committed and does not create another journal or audit row. Do not copy a request key into a different draft. The API starting a replacement entry.

The workspace loads active GL accounts independently from journal-list paging and entity refreshes. It follows the account endpoint’s authoritative total through every 500-row page and publishes options only after the full, duplicate-free population arrives; a changed total, repeated row, malformed page, or premature empty page is a retryable dependency failure rather than a silently truncated chart. While that directory is loading, failed, malformed, or truly empty, the modal labels the exact state and blocks submission instead of presenting an unexplained empty selector. Retry accounts refreshes the directory without closing the modal or discarding the draft; a truly empty chart links to Chart of Accounts for setup.

Every operator-created entry enters pending_approval, including adjusting entries and entries with a future reversal. Pending entries do not affect the ledger or statements. A requested future reversal is saved as intent and is not posted until approval. The routed the relevant workflow page shows pending entries directly in the list/detail surfaces and exposes an approve action to authorized users. The backend blocks creator self-approval through the shared separation-of-duties control; a documented, audited single-operator exception is available only when that is the tenant’s only qualified path.

Pending journal approvals also appear on Trial Balance, P&L, Balance Sheet, Cash Flow, and their exports when they are in the selected entity/date scope. The warning gives the count and amount excluded from posted totals and opens the same filtered Journal Entries approval queue. Treat the statement as incomplete until those journals are resolved; a balanced total does not remove this warning. If Keystone cannot read the warning authority, it says that state is unavailable and does not show a zero or clear result.

Account names and amounts in Trial Balance, P&L, and Balance Sheet link to the same account in General Ledger with the selected legal entity and report dates preserved. Chart of Accounts supplies the same entity/account scope without inventing a date range. Journal numbers in General Ledger then open the exact entity-scoped journal detail. If entity authority is unavailable, these pages keep the unavailable state and do not issue an unscoped drill-down.

Account activity is paged by the server. The workspace shows the visible line range and complete filtered count, and keeps the page in the URL for browser back/forward navigation. Opening and closing balances still describe the full selected account/date population; they are not subtotals of the visible page.

Approve a Pending Journal Entry

Approves a pending_approval entry and posts it as the auditable maker-checker completion step. The approver needs accounting-management authority for the entry’s selected company entity. Keystone rechecks that both the original entry date and any scheduled reversal date are still in open fiscal periods immediately before posting. If a future reversal was requested, approval creates the original and its reversing journal together. Creator self-approval, a closed/locked/missing period, or a changed entry produces a truthful conflict or permission error; refresh the list/detail and correct the period or use another qualified operator. Repeated approval never creates another audit event.

Reverse a Journal Entry

Creates a new entry with all debits and credits swapped. Marks the original as reversed. Only one reversing journal may own the original. A repeated or concurrent reversal returns a state conflict; refresh the original and use the already-created reversing entry. Journals owned by invoice, payment, credit, or other receivable lifecycles must be corrected through that source workflow.

General Ledger

The GL provides a detailed view of all posted transactions.

Paginated Ledger

The General Ledger workspace requests 25 rows at a time and performs search, account/date filtering, sorting, and paging on the server. Its count label therefore remains truthful beyond the first 50 rows and while filters are active. Loading, no-results, and retryable API-error states are displayed in the ledger region without presenting stale rows as current data.

Account names in Cash Flow and Cash Position open the General Ledger with the report’s exact company, account, and date or as-of boundary. Aggregate totals remain labels because they do not identify one ledger account.

Account Activity Detail

All activity for a single account with:

• opening_balance_cents – balance as of the day before date_from
• lines – all transactions in the date range
• closing_balance_cents – computed from opening + net activity

Currency basis

Ledger line debit and credit amounts are shown in the line’s recorded transaction currency. Functional amounts are separate evidence in the selected entity’s functional currency. A missing line currency or functional amount is shown as Unavailable; it is never inferred as USD or displayed as zero. Account opening, running, and closing balances use functional amounts only. If the selected population lacks complete functional evidence, the balance is unavailable rather than a misleading total. Journal Entry totals disclose when their transaction currencies are mixed and expose functional totals separately when every line has functional evidence.

When you open Review scoped GL activity from a deferred-revenue schedule, Keystone adds that schedule as a control scope. The activity list, opening balance, closing balance, and running balances then include only the selected account’s recognition journal entries linked to that schedule and their direct reversal entries. The service-period dates, paging, and account filter remain additive. Change the account or use Show all account activity to return to ordinary account activity.

If the schedule is missing or belongs to another tenant, Keystone returns the same not-found result and does not fall back to a broad account view. Correct the selected schedule or remove the schedule scope before retrying.

Budgets

Budgets let you plan spending by GL account and month for one selected company entity, then compare against actual GL activity in that entity’s functional currency. The entity selector is the authority bar: changing it cancels stale reads, clears cross-entity evidence, and loads a server-paginated population. A recoverable refresh failure keeps previously verified rows for the same entity visible with a warning; it never presents the failure as an empty budget list.

Create a Budget

Fields:

• name (required) – e.g., “2026 Operating Budget”
• fiscal_year (required) – 2000-2100
• lines – array of budget line items:
• month (required) – 1-12
• amount_cents (required)

No duplicate lines are allowed for the same account and month. The server derives and stores the selected entity’s supported functional currency; the UI shows that currency before entry and every amount control uses integer minor units. If entity currency is missing or invalid, creation and amount editing stay unavailable until Company Profile is corrected. The UI never substitutes USD or displays an unknown amount as zero.

Budget names are unique within the fiscal year and selected legal-entity scope, so the same name may be used independently for different entities. Every budget line inherits the header’s entity scope. Accounts come from the tenant’s common chart of accounts; an entity-scoped accounting viewer may search and page through that server-owned reference list, but account rows do not acquire an invented entity scope. Grid totals are explicitly totals for the visible account page. Keystone retains every stored line in the save command even when its account is on another page or outside the current search. A stored line whose account is inactive or missing remains visible as recovery evidence and disables amount replacement so it cannot be silently deleted.

Budgets start in draft status.

Budget Lifecycle

• Draft: lines can be modified
• Active: locked for tracking; cannot modify lines
• Closed: finalized

Update a Budget

Entity and currency are immutable after creation. Draft budgets can update their name and lines; lifecycle status follows draft -> active -> closed. Existing legacy rows without entity/currency authority remain visible to a tenant-wide reviewer as read-only legacy_unassigned records. Rename, status change, line replacement, and delete all remain unavailable until controlled recovery establishes their scope.

Budget vs Actual Variance

Compares budgeted amounts against posted, non-reversing functional-currency GL activity for each account/month combination. Returns:

• Per-line: budget and nullable actual/variance amounts and percentage
• Totals: nullable total budget, actual, and variance

When functional-currency evidence is missing or inconsistent, the report says unavailable and retains null actuals/totals. It does not convert missing evidence into $0.00.

Landing Budget Coverage

• ready means every scoped entity has one authoritative budget and all included entities share one disclosed currency, so totals are available.
• partial means homogeneous-currency totals cover only the returned included budgets; inspect entity_population and the unassigned-population disclosure before relying on the result.
• no_budget means no eligible budget covers the scope; totals are intentionally absent. This can occur in the default-company view even when it discloses unassigned transition records; it does not mean the budget or actual is $0.
• currency_unavailable means at least one selected budget lacks matching entity currency evidence; totals are intentionally absent.
• mixed_currency means the rollup contains more than one functional currency; Keystone does not sum unlike monetary units, so totals are intentionally absent.

The endpoint requires keystone.accounting.view. A missing permission, dependency failure, or malformed response is not a zero-budget result; correct access or retry after the accounting authority recovers.

Financial Statements and Reports

Select the company first

Financial Statements requires a company entity in the URL before it loads Trial Balance, P&L, Balance Sheet, Cash Flow, accounting AR Aging, or an ordinary statement export. Select the company in the workspace picker; Keystone records that exact entity in the URL so the view can be shared and refreshed safely. It does not replace a missing selection with a default company, a parent rollup, unassigned rows, or all-tenant data. If a link references an inactive or unavailable company, choose an active company you are permitted to view; foreign/inactive selections are not disclosed. Report data clears while the selection or report date changes and a failed request never leaves prior-company figures visible.

The same rule applies to the complete Accounting AR Management workspace. Its company picker scopes AR Aging and drill-down, Overdue Invoices, CECL preview, write-off requests, and the financial-approval queue. The selected tab and server page are recorded in the URL. Changing company clears prior-company amounts and in-flight mutation results; a failed refresh within the same company keeps the last verified evidence visible with a warning.

Choose live or published evidence

An older aggregate-only close package, corrupt package, or superseded package cannot be presented as current published statement evidence. Keystone labels it unavailable or superseded instead of guessing detailed rows. Correct the close/package authority or choose Live ledger. If a shared link contains a malformed close ID, the workspace preserves and reports that invalid selection rather than silently falling back to live numbers.

Trial Balance

• As of Date: The end date for the trial balance (defaults to today).
• Period Start (optional): When set, revenue and expense accounts show only operational activity within the [period_start, as_of_date] range. Balance sheet accounts show cumulative operational balances through as_of_date. Leave empty for a cumulative trial balance.
• Export CSV / Export XLSX: Choose a format, then queue an auditable export using the currently selected entity, dates, and filters. Financial Statements exports Trial Balance, P&L, Balance Sheet, or Cash Flow; General Ledger exports the visible ledger or account-activity filters; Journal Entries exports every authoritative journal line for the visible filters; Bills exports canonical AP Aging using the as-of date returned by the server. CSV includes machine-readable scope/disclosure records and XLSX includes a Scope sheet. Both identify the entity, date basis, filters, and filter-evidence hash.

After reload or navigation, the workspace asks for the newest export belonging to the signed-in operator for the exact company and report type, then resumes polling it. A permission or dependency failure is shown as recovery unavailable and keeps the current inputs intact. It never substitutes another user’s job, another company’s artifact, or an empty-success message.

If status polling fails, the last known job state remains visible. Select Check status again after connectivity returns; do not queue a duplicate export merely because a status request failed. A rejected manual retry leaves the failed job and its retry action in place so the operator can correct the reported dependency problem and try again. A completed job without a server filename remains unavailable and offers status refresh instead of downloading a client-renamed blob.

Changing the visible report tab, filters, or dates within the same company does not change an existing job’s identity; the alert continues to show the report, format, requested view, filters, and dates that were actually queued. Changing company retires that job immediately, so a late poll or download cannot expose the prior company’s artifact. Queue a new export for the new company or report. If export permission is removed, the same-company job evidence remains visible but queue, retry, and download actions disappear; hand a terminal failure to an operator with report-export permission.

For a cumulative report, Keystone shows the server-derived balance result and exact cents difference; only a balanced server result means the totals tie. When Period Start is set, the report intentionally combines cumulative balance-sheet accounts with period-only revenue and expenses. Keystone labels this mixed basis as not applicable for balance checking and explains the caveat; do not use it to assert that the books are balanced. If the balance result is unavailable, treat it as unavailable rather than balanced.

Trial Balance and Profit & Loss treat year-end close journals as transfer mechanics, not operating activity. After a year is closed, those reports continue to show the original revenue and expense activity; a reversal of the close is excluded on the same basis. Balance Sheet continues to include the transfer into Retained Earnings and removes the synthetic Current Year Net Income line after the transfer, so earnings appear once rather than twice.

All accounting statement and close-adjacent report routes now run through tenant-scoped request sessions and explicit tenant filters on GL-owned tables. Foreign-tenant journal rows are excluded before output instead of relying on UI filtering or RLS alone.

Profit & Loss (Income Statement)

Full ASC 220 multi-step income statement with sections:

1. Revenue – operating revenue accounts (excludes other_revenue, contra_revenue)
2. Cost of Goods Sold – expense accounts with sub_type cogs
3. Gross Profit – revenue minus COGS (subtotal)
4. Operating Expenses – all non-COGS, non-tax, non-other expense accounts
5. Operating Income – gross profit minus operating expenses (subtotal)
6. Other Income – non-operating revenue (sub_type other_revenue)
7. Other Expenses – non-operating expenses (sub_type other_expense)
8. Income Before Tax – operating income + other income - other expenses (subtotal)
9. Tax Expense – tax-related expenses (sub_type tax)
10. Net Income – income before tax minus tax expense (final total)

Each line item and subtotal displays a percentage-of-revenue column showing the item as a percentage of total revenue (e.g., “42.1%”). Zero revenue displays “—”.

Supports compare_period parameter:

• prior_year – same period in the previous year
• prior_period – immediately preceding period of the same length

When comparison is selected, each account row and section total shows Current, Prior, and Variance values supplied by the server. Accounts with activity in only one period remain visible with zero in the other period. The statement header identifies the exact company entity, posted-ledger basis, and Live statement status. Live means the result was recomputed from the current ledger; it is not the frozen statement evidence from a completed close package.

Balance Sheet

Returns server-derived difference_cents (assets minus liabilities plus equity) and required is_balanced. A nonzero difference is shown as an error with the exact server value. If either field is unavailable, the workspace warns that the statement must not be treated as balanced. Inactive accounts with posted in-scope balances remain visible so deactivation cannot hide financial history.

With a comparison date, every account row and section total shows the server-aligned Current, Prior, and Variance values. The header prints the exact company entity and ledger basis and explicitly identifies the statement as live rather than published close evidence.

Balance Sheet signs follow the statement equation rather than each account’s configured normal balance. Asset lines are debit minus credit; liability and equity lines are credit minus debit. A credit-normal asset such as Allowance for Doubtful Accounts therefore appears as a negative contra-asset and reduces total assets. The visible statement, CSV export, annual package, and frozen close package use this same rule.

Cash Flow Statement

Uses the indirect method (the standard presentation for non-public companies). Sections:

• Operating Activities – starts with net income, adds back non-cash expenses (depreciation/amortization), then adjusts for changes in working capital accounts (AR, AP, prepaid expenses, accrued liabilities). An increase in AR reduces operating cash (revenue recognized but not collected); an increase in AP increases operating cash (expenses incurred but not paid).
• Investing Activities – changes in fixed asset accounts and accumulated depreciation
• Financing Activities – changes in equity accounts and long-term liabilities

Returns method: "indirect", opening/closing cash balances, and net change for the required selected company entity. Use prior-period or prior-year comparison for a like-for-like statement. The statement “proves out”: opening cash + net change = closing cash.

The Compare control requests either the immediately prior like-length period or prior year. Keystone aligns account rows and its named synthetic rows on the server, then displays Current, Prior, and Variance values along with the exact comparison dates. The entity/basis disclosure and Live statement label have the same meaning as P&L and balance sheet.

The screen has a second fail-safe for legacy or stale payloads: a non-zero difference shows Cash flow is unreconciled, Classified closing cash (unreconciled), and Actual posted closing cash. Actual posted cash remains authoritative and the screen does not display the ordinary Closing Cash Balance label. Correct the account classification or journal evidence, then select Generate again; retry the export only after the statement reconciles.

AR Aging (Accounting)

Detailed AR aging from unpaid invoices for the required selected company entity, grouped by customer. The visible columns are Current, 1-30, 31-60, 61-90, 91+, and Total. The five age buckets are non-overlapping: day 90 remains in 61-90, and 91+ means strictly greater than 90 days. Every customer row and the Totals footer expose all five components and reconcile to the displayed Total. CSV export preserves the same five columns, total, entity scope, dates, and basis.

Bucket rows show both outstanding value and invoice count. Select a non-empty customer bucket, a non-zero footer bucket, or the overall footer total to open the matching server-filtered invoice population, including customer, status, issued and due dates, exact days past due, payments, credits, and outstanding balance. The invoice-detail API retains 90+ as its backward-compatible filter token even though the operator label is 91+.

The Dashboard and Finance receivables cards use the same definition, including dedicated migrated opening receivables. Finance follows the company in the global authority bar and opens only the detail URL returned by the server. If a refresh fails, a same-company prior value is labelled as last known; without a prior value the card shows unavailable, never $0.00. Change company or retry the workspace before relying on the amount.

Invoice detail is loaded in server-paginated pages using the same report date and bucket boundaries as the summary. The dialog reports loading, retryable failure, and no-result states. Paging labels reflect the full filtered invoice count rather than the current page size.

Customer names, bucket amounts, and customer totals open AR Management with the same company and as-of date encoded in the URL. The invoice-detail request keeps those URL filters across paging and browser back/forward navigation. Each row uses server-provided invoice and issuance-journal links. A missing link or denied invoice permission is shown as unavailable or access-required evidence, never reconstructed in the browser. Retry keeps the selected customer, bucket, date, and prior successful detail visible until replacement evidence arrives.

Operators need keystone.accounting.view. A customer filter cannot reveal customers or invoices from another tenant.

Cash Position

In-Product Statements Workspace

The the relevant workflow page consolidates these accounting workflows for operators. Every ordinary statement response and its queued/scheduled CSV uses the same exact entity, normalized effective date(s), includes_unassigned=false, and accounting basis. Status, retry, download, delete, and list actions re-check that saved entity authorization; delivery workers re-check it before rendering.

• Trial Balance, P&L, Balance Sheet, and Cash Flow statement generation
• AR Aging and Cash Position reporting
• P&L compare-period review (prior_period or prior_year)
• Balance sheet comparison-date review
• Fiscal period management (create, close, reopen) for users with keystone.accounting.manage
• Year-end close execution for users with keystone.accounting.manage

LLC Member Management

For multi-member LLCs and partnerships, Keystone tracks members, ownership percentages, distributions, and K-1 data per legal entity. Select the company entity at the top of the workspace before reviewing or changing member records. The selection is retained between visits and every list, create, and K-1 request carries that entity scope.

List Members

Add a Member

Fields:

• name (required)
• email
• ownership_percentage (required) – active ownership within this legal entity cannot exceed 100%
• join_date

Adding a member automatically:

1. Creates a Capital sub-account (30xx series) under Owner’s Equity
2. Creates a Draws sub-account (31xx series) for distributions
3. Links both accounts to the member

Update a Member

Ownership percentage changes and inactive-to-active transitions are validated against other active members in the same legal entity. Keystone serializes concurrent ownership changes so two simultaneous requests cannot both pass an outdated total.

Record a Distribution

Fields:

• amount_cents (required, > 0)
• distribution_date – defaults to today
• notes

Automatically creates a journal entry:

• draw: debit Draws account, credit Cash
• return_of_capital: debit Capital account, credit Cash

The journal entry is posted to the member’s legal entity. A distribution cannot silently fall back to another entity’s fiscal period. Keystone freezes the selected entity’s supported functional currency and canonical profile evidence on both the distribution and its journal lines. If that authority is unavailable, it refuses the new distribution instead of assuming USD or using today’s profile for historical cents.

K-1 Summary

Returns Schedule K-1 data when the exact entity’s distribution and operational-ledger populations have complete functional currency evidence:

• ownership_percentage
• total_distributions_cents – all distributions in the year
• allocated_income_cents – member’s share of that legal entity’s net income (based on ownership %)
• Detailed distribution list

If any historical record is legacy, mixed, or incomplete, the workspace identifies the unavailable currency authority and withholds functional totals. Historical evidence remains visible for review; it is not converted or shown as an unlabeled monetary amount.

Monthly Close Process

The monthly close ensures all transactions are recorded and verified before locking a period.

Fiscal Periods

Fiscal periods represent months. Every journal entry must fall in an open fiscal period.

Create fiscal period:

Fields:

• year (required)
• month (required, 1-12)

No duplicate year/month combinations allowed.

List fiscal periods:

Close a fiscal period: Select Run close for the open period. Keystone opens the Close Runs workspace with the legal entity and fiscal period preselected. There is no direct fiscal-period close API: the period closes only when the controlled checklist completes or an authorized second operator approves a blocked close with a reason. This prevents depreciation, accrual, CECL, tax, FX, snapshot, and variance controls from being bypassed.

The close checklist does not treat missing control-account data as zero. Its open AR/AP step requires one tenant-owned 1200 and 2000 account for the selected legal entity, reads their period-end GL balances, and reconciles 1200 to the immutable receivable-event population for the same entity and date. Missing or ambiguous accounts, query failure, missing event coverage, or an event/GL divergence is a failed check with unavailable or mismatched evidence; correct the lineage before approving the close.

The close also verifies two non-overridable subledger gates while it holds the selected fiscal-period lock. AP Aging must be available and reconcile to AP control for the same legal entity and period-end date. Every configured or posted cash-control account must have imported entity-scoped statement evidence and a completed reconciliation covering the period with an exact zero difference. A missing feed, legacy unassigned transaction/session, stale or unavailable source, incomplete reconciliation, AP variance, or even a one-cent bank difference blocks the close and remains blocked at approval. The checklist shows the recovery reason and opens the relevant Bank Reconciliation or AP Aging workspace; correct the evidence, rerun the close, and do not use approval to bypass it.

Re-open a fiscal period:

Enter a specific correction or control reason in the confirmation dialog. Reopening a closed period permits new postings and atomically supersedes every frozen close package previously captured for that legal entity and period. The original package remains visible and downloadable as historical evidence, with a superseded banner, reason, actor, and time; it is never the current authoritative close output. Complete a replacement close after corrections. Locked periods cannot be re-opened. If either the reopen, package supersession, or audit write fails, Keystone saves none of those changes and tells the operator to retry.

Close Runs

Before close can continue, resolve every pending journal approval in that period. The close detail reports the scoped count, integer-cent amount, and journal evidence when it is blocked. Approve close cannot override this control: approve the journals with a qualified independent operator, refresh the close detail, and run a new close after the period remains open.

Initiate a close run:

Fields:

• variance_threshold_pct – for flagging unusual variances (default from config)

1. Claims the queued run and records worker/heartbeat metadata.
2. Runs automated checklists (unreconciled transactions, missing entries, etc.).
3. Computes variance reports.
4. Takes a snapshot of account balances and records terminal audit evidence.

The lifecycle states are:

• pending – queued for a worker
• running – claimed/executing, or waiting for recovery after a cancellation request
• completed – all checks passed or an authorized override was approved; the period is closed
• blocked – exceptions found; the period remains open and requires review
• failed – execution or recovery failed; the period remains open
• cancelled – cancellation is terminal; the period remains open

View close run results:

Returns checklist results, exception count, variance report, and snapshot data.

back/forward return to the same server-fetched run. A run from another entity, an inaccessible run, or a late response from a prior selection cannot replace the visible detail. When a same-scope refresh fails, the last confirmed detail remains visible with the failure and a retry action; do not interpret it as fresh. Checklist controls, including foreign-currency remeasurement, use operator labels instead of storage keys. A journal link appears only when the checklist contains a positive journal ID; bank reconciliation, AR aging, AP aging, and fixed-asset recovery links preserve the validated entity and available period date. No authoritative recovery destination means the backend did not provide enough typed evidence—do not infer a record from the detail text.

Coordinate and recheck close work

Open a close-run detail and use Close checklist coordination after the worker has generated task evidence. Each task displays the authoritative engine result separately from its coordination state. A close operator can:

1. Search the Owner selector for an active Portal user who currently has close permission for the selected legal entity, and set an optional due date. Use Assign to me for the signed-in operator. The server performs the same current-permission check before saving. Inactive groups and expired or revoked grants are excluded. If the Portal directory has never synced, is incomplete, failed, syncing, or is more than 24 hours stale, the selector reports the dependency and offers retry instead of showing stale eligibility. An inactive, permission-revoked, or missing assigned owner remains visible as unavailable evidence until you select an eligible replacement or unassign the task; Keystone never asks you to reconstruct a Portal user ID.
2. Record append-only review comments. A failed comment request keeps the entered comment and previously loaded evidence visible; retry the same task instead of treating the comment history as empty. Comment authors are shown by their tenant directory label; inactive and unavailable historical actors remain explicitly labeled without exposing a raw Portal ID.
3. Record an Evidence acknowledgment for the exact result revision. Explain what was reviewed. This does not mark the checklist step passed and does not override the close engine. The acknowledging actor uses the same active, inactive, or unavailable evidence label as comments.
4. Correct the underlying source problem through the task’s verified evidence link. For a blocked, failed, or cancelled run whose period is still open, enter a reason and choose Queue full replacement run. Keystone cancels a blocked source and queues one new run that executes the entire canonical checklist. It never reruns just the selected step.

If an acknowledgment or replacement request times out, keep the same text and retry the same command. The UI reuses the command key so the server can return the prior result without duplicating evidence or runs. A recovered replacement is labeled and links to its exact company entity and close-run ID. On a version conflict, permission change, or stale fingerprint, refresh task evidence before retrying; do not change the result fingerprint or create a manual replacement.

Checklist coordination unavailable means the engine has results but normalized task evidence cannot currently be established. The close engine has not generated checklist task evidence yet means no results exist. Neither state is an empty or completed checklist. Operators without effective entity close permission can inspect the evidence but cannot mutate it.

If the new-close dialog has no open period, use Open financial statements to create or reopen a fiscal period. This opens the existing entity-scoped fiscal-period operator surface; return to Close Runs after the period is open. The dialog shows the CECL loss-rate policy basis before submission. Expand Review assumptions only when current reserve evidence requires a change. A failed create keeps the selected period, CECL rates, scenario, and review note for correction; it does not silently restore defaults.

When a failed run names an earlier open period in the canonical prior period YYYY-MM is still open failure, the detail exposes Repair YYYY-MM. That action opens a replacement close-run review preselected to the exact blocking period; it does not override the blocker or mutate the failed run. Complete the earlier period, then create a new run for the originally requested period.

Completed runs render a Frozen close package with the as-closed trial balance, profit and loss, balance sheet, pinned exchange rates, depreciation journal evidence, recurring accrual entries, prepaid-amortization entries, and CECL/bad-debt result. The page shows the fiscal period end and completion time. Evidence is frozen with the close; Keystone never substitutes later live statements or current control rows.

A completed detail always says the close completed and the fiscal period closed, even if an older worker message still contains blocked-run recovery instructions. Approve Override and Cancel run are not available after completion. If CECL was later reversed or recalculated, the completion message identifies that post-close remediation while the frozen package remains unchanged.

After a CECL reversal, the current state and operator-action history show the reversal entry, later open posting period/date, and reason. Reverse CECL is removed because the entry is already reversed. Recalculate CECL remains available only to an authorized close operator when a later open fiscal period exists for the same company. If it is unavailable, create or reopen the appropriate later period through the supported fiscal-period controls; do not repeat the reversal or edit journal/close records directly.

The package balance sheet is cumulative through the fiscal-period end. Its equity total includes both posted equity and fiscal-year-to-date net income that has not yet been closed into retained earnings. Contra-revenue, contra-asset, and tax accounts retain their statement-side signs. Keystone blocks completion instead of freezing a package when assets do not equal liabilities plus equity.

Operators with keystone.reports.export can download four server-rendered forms:

• PDF — human-readable close book with entity/period/completion metadata, statements, control evidence, approval context, and canonical package SHA-256. P&L, balance sheet, FX, depreciation, accruals, prepaid amortization, and bad debt.

• Excel — analysis workbook with separate statement and evidence worksheets.

All four formats use the same frozen logical payload and canonical SHA-256. The hash appears in the filename, identity across formats; it is not a hash of the PDF or ZIP bytes.

Attach a close to an audit binder:

1. Select the completed close run for the exact legal entity and fiscal period. Do not use a blocked run’s provisional checklist evidence.

2. Confirm the displayed period end and completion time, then download both PDF and ZIP / CSV. the X-Close-Package-Canonical-Hash download header captured by your controlled download process.

3. Retain the PDF, untouched ZIP, and manifest/hash together. Attach those artifacts to the audit binder and reference the close-run ID. Do not replace them with statements re-run after the period closed.

Reopened-period packages display their invalidation state and cannot be exported. Complete a new controlled close after corrections and attach the replacement run; keep the old run’s invalidation audit evidence. Blocked, running, pending, failed, and cancelled runs are not authoritative and offer no downloads. If final snapshot or package validation fails during approval, the run remains blocked and the period remains open: correct the reported evidence problem and retry the controlled approval. Do not close the period directly.

Legacy completed packages may show statements with Legacy package — close-control evidence unavailable. Do not reconstruct missing historical evidence from current data. If a completed package is missing or malformed, record the close-run ID, contact support, and do not treat a re-run statement as the original close book. Operators without keystone.reports.export can review permitted close details but cannot download a package.

New snapshots preserve the selected legal entity’s functional currency and render in that currency. Legacy snapshots that predate currency capture are labeled currency unspecified; Keystone never silently assumes they are USD.

In the the relevant workflow workspace, blocked runs now show a readiness summary, source-linked journal-entry drill-down for actionable checklist failures, and account-ledger evidence for variance rows. The evidence links stay read-only; they are there to explain the exception before an override is used.

Approve a blocked close run:

Fields:

• reason (required) – explanation for overriding exceptions

The approval record preserves the reason and canonical approver identity on the close-run detail view. The creator identity is shown separately from the approver.

Cancel a close run:

If a checklist warning does not expose a source record, the UI shows that explicitly instead of pretending there is a drill-down.

Accrual Templates

Set up recurring accruals that are automatically applied during the close process.

List accrual templates:

Create accrual template:

Fields:

• name (required)
• description
• amount_cents (required, > 0)

In the the relevant workflow template modal, the debit and credit account pickers are searchable. Type an account number or name to query active GL accounts through the account lookup API; the picker is no longer limited to the first page of the chart of accounts.

Deactivate template:

Soft-deletes (deactivates).

Recommended Monthly Close Workflow

1. Ensure all invoices for the month are sent
2. Record all payments received
3. Approve and pay all expenses/bills
4. Import and reconcile bank transactions
5. Review trial balance
6. Initiate a close run
7. Resolve any exceptions (or approve with reason)
8. Close the fiscal period

Year-End Close

Year-end closing zeros all revenue and expense accounts into retained earnings.

Keystone uses the selected company’s active default profile as the single fiscal-calendar authority for close and statements. Alternate profile keys, inactive companies, and another tenant’s profiles do not affect the range. A company without that authoritative profile uses January through December.

Fields:

• fiscal_year (required)

Request a close:

Approve and execute:

A different qualified accounting-close operator selects Approve requested close. Keystone verifies entity permission and maker-checker rules, then rechecks the close prerequisites:

• All 12 fiscal periods for the selected entity/year must be closed.
• No existing closing entries can already own the year.

On success it:

1. Calculates net income (revenue minus expenses) for the year.
2. Creates closing journal entries: - Zeros each normal credit-balance revenue account by debiting Revenue and crediting Retained Earnings (account 3200); a net-debit revenue balance reverses that direction - Zeros each normal debit-balance expense account by crediting Expense and debiting Retained Earnings; a net-credit expense balance reverses that direction - Transfers the exact signed net result directly to Retained Earnings
3. Locks all 12 periods, records the maker and approver in the audit trail, and returns the closing entries and net income.

Year-end close is atomic. If approval execution cannot close an account, Keystone rolls back every closing entry from that attempt, leaves all 12 periods closed, keeps the request pending for safe retry, identifies affected accounts without exposing internal exception text, and never reports partial success. A completed request cannot be approved again.

Recover a locked year

An operator with keystone.accounting.close for the selected company entity can choose Prepare locked year for correction in Financial Statements. Enter the reviewed reason and confirm. Keystone verifies that the entity has exactly 12 locked periods and posted year-end closing evidence, then moves those periods to closed and records the complete transition in the audit trail.

This recovery does not reopen a period and does not change or delete posted journal entries. After recovery, use the existing Reopen action with its own reason to permit corrective postings, and correct posted history through reversing entries. Repeating the recovery, selecting another tenant/entity, or attempting it against mixed/incomplete period states is rejected.

Deferred Revenue Dashboard

Navigation: Customer-to-cash revenue-model lifecycle > Deferred revenue, or the command palette

The Deferred Revenue page provides full visibility into ASC 606 revenue recognition:

Select the company and as-of date first. Both remain in the URL with schedule, tab, status, and page focus so a reviewed view can be reopened safely. The four summary cards show remaining schedule liability, posted GL liability, reconciliation variance, and recognized year to date in the selected company’s authoritative functional currency. Unknown or incomplete evidence is shown as unavailable, never as zero or USD.

The Total Deferred Balance is accounting truth, not a schedule estimate. It includes only posted journal entries against the signed-in tenant’s GL account

2600. Draft or pending-approval entries and another tenant’s account activity do not affect the card.

Canonical GL tie-out

The reconciliation card and summary come from the same exact-entity, one-statement report population. A status filter changes the schedule page but does not narrow the full-population GL comparison. A failed refresh retains the previous same-scope evidence with an error; changing company clears it and late responses from the prior company are ignored.

The control shows the server-calculated GL balance, active-schedule remainder, variance, schedule counts, and any explanatory difference rows. A clean result means the variance is zero and there are no stale recognition totals, blocked schedule residuals, cancelled schedule residuals, or invalid posted recognition-to-journal links. A zero variance by itself is not a clean tie-out.

• Clean, including no activity: GL 2600 and the active-schedule remainder are both zero (or otherwise equal), exception counts are zero, and the page identifies the result as tied out.

• Monetary mismatch: review the GL 2600 activity and active schedules. The difference row calls out a GL-to-schedule variance; investigate manual GL activity, a cancelled schedule with residual liability, or stale schedule recognition totals before relying on the balance.

• Schedule or evidence exception: a stale recognition total, blocked or cancelled schedule with remaining liability, or posted recognition entry that lacks a same-tenant posted journal link makes the control an exception even when the money happens to tie. Use the schedule and invoice identifiers in the row to investigate the underlying record. Correct blocked recognition in its owning workflow, and correct an invalid journal link or recognition-entry status before treating its amount as accounting evidence.

• Read failure: use Retry or Refresh after correcting the reported access or service problem. Do not infer a clean result from the summary cards while the tie-out is unavailable.

If the page reports that GL account 2600 is missing, configure the tenant’s Deferred Revenue liability account before retrying. The tie-out does not post journals, repair schedules, or override a cancellation; make corrections in the controlled accounting or billing workflow, then reload the control. Access requires the accounting-view permission. Operators who do not have it need an appropriately authorized accounting administrator to perform the review.

Schedules Tab

Lists all deferred revenue schedules with:

• Customer name and invoice number
• Total deferred amount, recognized amount, and remaining amount
• Visual progress bar showing recognition percentage
• Service period (start and end dates)
• Status badge (Active, Blocked, Fully Recognized, Cancelled, Superseded)

Use View to open server-paged immutable recognition-event and journal evidence. Links carry the same company scope into the performance-obligation or general-ledger workspace; the page does not expose raw internal identifiers as operator labels.

Open a blocked schedule to inspect its exact entity, currency, invoice-line, obligation, and profile evidence. Legacy or ambiguous source rows are audit-only and have no force-link action. For a transient entity/profile dependency, restore the canonical active entity authority; the bounded recognition worker revalidates the unchanged frozen chain and resumes idempotently. Contract-line, currency, or amendment drift stays blocked and must be corrected in the originating contract workflow rather than overwritten from accounting.

Waterfall Tab

Projects expected revenue recognition over the next 12 months:

• Visual bar chart showing monthly projected amounts
• Tabular breakdown with monthly totals
• Uses the same day-based pro-rata logic as the automated recognition engine

Recognition History Tab

Shows deterministic server-paged recognition events across all schedules, with source/profile completeness, canonical money, journal drill-through, mobile cards, and newest-first ordering. An unavailable population withholds money.

Trust-boundary note: these routed deferred-revenue views now execute through a tenant-injected request session and keep explicit tenant filters on schedules, recognition entries, customer joins, invoice joins, and the posted GL 2600 balance lookup. A foreign-tenant schedule ID no longer resolves just because the numeric ID exists.

How Schedules Are Created

Deferred revenue schedules are created automatically when an invoice line has a multi-day service period. No manual schedule creation is needed. Each new schedule is bound to the exact invoice line that generated it. Contract lines additionally bind their sold-contract version and obligation; a one-off manual service line freezes its own immutable line snapshot and entity/profile currency evidence rather than inventing contract provenance.

How Recognition Works

The daily scheduler processes exact tenant/entity schedules in bounded locked batches. For each due period it uses the shared exact allocation policy, posts DR Deferred Revenue 2600 / CR the frozen revenue account, persists an immutable recognition event and entry, and only then advances schedule and obligation counters. Each schedule is atomic: another schedule may succeed when one fails, while the failed schedule retains a typed blocked reason. Transient dependency failures are reconsidered on a later scheduler or close rerun; profile, currency, or source drift remains blocked. A close cannot pass while a failure or bounded continuation remains.

Deferred Tax Summary

Use this read-only accounting route to inspect current deferred tax assets and liabilities:

• as_of_date to compute the summary for a point in time instead of today

The response includes:

• itemized temporary-difference rows
• net DTA, net DTL, and net position
• the effective tax rate used for the current snapshot

Trust-boundary note: the deferred-tax summary now runs through the signed-in tenant session and carries tenant scope through company-profile, fixed-asset, deferred-revenue, account-balance, and snapshot lookups before returning the report.

Pay an Approved Bill

Record partial or full payments from the approved bill. Keystone prevents the bill’s approver from also recording its payment when the tenant has another operator with Accounting management permission. A tenant with only one accounting operator can continue through the existing single-operator control exception; the server durably records that exception before allowing the payment workflow to continue. A multi-operator denial is also retained even though the protected financial transaction is rejected.

The Bills workspace searches bill number, vendor invoice reference, and same-tenant vendor name on the server. Status/date filters, allowlisted sorting, pagination, and totals are also server-owned; a page never represents the first 50 records as the complete population. A changed-query failure clears the old scope and offers retry. A same-query refresh failure may retain the prior page only when it is explicitly labeled unavailable/stale.

Select the company entity in the workspace bar before creating a bill or purchase order. The create dialog displays that entity’s supported functional currency; Keystone derives and rechecks it on the server rather than trusting a browser default or vendor preference. If the entity has no supported functional currency, creation is unavailable until Company Profile is corrected. Foreign-currency Bill and PO creation is unavailable until Keystone stores immutable source-rate and functional-amount evidence through the subledger and posting chain; do not use a live FX quote as a workaround. Approve on a bill now records an approval request only. It shows approval requested and does not claim an AP/GL posting. In the Bill Financial approvals queue, review the server-provided entity/currency amount tier and enter a reason before an independent qualified operator approves or rejects. The requester cannot decide their own request except for the documented audited single-operator policy. The executor rechecks the current bill, entity, canonical currency, period, and matching authority before any posting. If the queue or policy is unavailable, retain the bill and use its scoped Retry only for a server-marked retryable execution failure; do not submit a second bill or treat an empty/unavailable queue as approval.

Approval thresholds are always stored in the selected entity’s canonical functional currency. A request retains its transaction amount and currency separately. Keystone selects a tier only when it has immutable functional-basis evidence: current workflows with a transaction in the functional currency use that exact amount; a foreign-currency workflow without a persisted conversion/rate basis is unavailable and cannot be approved by applying a live rate or assuming a dollar amount. The queue labels both amounts when they differ.

For a PO-backed bill, final execution requires the visible matching revision and a current complete active match run. A stale, incomplete, rejected, over-allocated, or superseded run cannot authorize AP/GL posting. If execution fails or conflicts, refresh the request and correct the current source evidence before submitting a new request when the old snapshot is no longer valid.

Purchase Orders

Purchase orders track vendor procurement commitments with an approval workflow.

Create a Purchase Order

Fields:

• currency (required, supported three-letter code) – the server derives and revalidates the selected entity’s canonical functional currency. A foreign transaction currency is unavailable until Keystone has immutable functional amount and exchange-rate evidence; the operator must correct Company Profile authority rather than rely on a USD default.
• po_number (required) – must be unique within the tenant
• order_date (required)
• expected_date – expected delivery date
• tax_cents – tax amount (default 0)
• notes
• lines (required, at least 1):
• description (required)
• quantity (default 1.0)
• unit_price_cents (required)
• amount_cents (required)

Subtotal and total are auto-computed from line items plus tax.

Account-directory loading and recovery

The line account is required. The selector searches eligible purchase accounts on the server: debit-normal expense accounts plus accounts explicitly classified as inventory, prepaid, or fixed asset. It excludes cash/bank, receivable, clearing/control, contra, inactive, and foreign accounts. While accounts load, the selector shows progress. A successful response with no eligible purchase accounts shows an explicit empty result. If the read fails, the create or draft-correction dialog keeps entered lines and previously loaded options, shows the backend detail, and provides Try again. Do not interpret an unavailable selector as proof that the company has no GL accounts.

If an older draft contains a now-ineligible or missing account, use Edit to correct it. Keystone shows the prior account label only as correction context, requires every affected line to be recoded to a currently eligible purchase account before saving, and then allows the corrected draft to be submitted. If another operator saved or advanced that draft first, Keystone rejects the stale action without discarding your entered correction; compare the current server version, reconcile the other operator’s changes, and deliberately reapply yours. Submission and approval also use the visible revision, so an unseen concurrent change cannot enter or clear the approval queue. Non-draft purchase orders are immutable through the edit action. Keystone will not create, save, or advance a priced procurement commitment with inconsistent arithmetic or invalid accounting classification.

Tax readiness failures direct operators to the Tax Brackets workspace and the publish action. User-visible recovery text does not expose REST paths or require API knowledge.

Purchase Order Lifecycle

• Draft: header fields and lines can be replaced through the tenant-scoped edit contract. Keystone validates duplicate numbers, vendor ownership, and line arithmetic before changing the draft, then records before/after audit evidence in the same transaction.
• Pending Approval: Submit for approval has locked the draft. Approve creates a financial approval request; it does not immediately advance the PO. The Financial approvals queue shows the selected entity/currency tier, required independent decision, and truthful retry/unavailable state.
• Approved: ready for receiving and billing
• Partially Received: some goods received against this PO
• Received: all goods fully received

Approve a Purchase Order

Use Submit for approval on a complete draft. Keystone records the submit event and moves it to pending_approval. Approve then creates or replays the same immutable approval request and leaves the PO pending. A different qualified operator opens the Financial approvals queue, reviews the server-selected entity/currency amount tier, supplies a decision reason, and approves or rejects. The requester cannot decide their own request; the limited single-operator exception is recorded by the server, not created by opening another browser session. The locked executor rechecks tenant/entity permission, policy tier, draft snapshot, active vendor, eligible accounts, exact arithmetic, and receipt/matching authority before it advances the PO. A conflict, unavailable dependency, or stale snapshot remains a visible failed/pending request with the indicated recovery action, never an approved PO by implication.

After approval, the PO detail exposes the next valid handoffs: Receive goods, Create linked bill, and, after receiving, Open matching. These commands route into the authoritative receiving, AP bill, and three-way matching workspaces with the PO context rather than leaving the operator at a terminal-looking detail modal.

Keystone evaluates approval eligibility when it returns each purchase order. When maker-checker rules require another operator, the list and detail view show that reason instead of offering an approval button that will fail. If a submit or approval request returns a definitive denial, the action-specific reason remains visible. If the request outcome is ambiguous, Keystone reloads the exact purchase order before describing its durable state; if that reconciliation is also unavailable, it reports the outcome as unknown and requires an explicit retry instead of claiming that no state changed.

Bill Matching Authority

Tenant-Safe Vendor Display and Recovery

Goods Receipts

Goods receipts document the physical receipt of goods against a purchase order. They are the second leg of three-way matching (PO -> Receipt -> Invoice).

Create a Goods Receipt

Fields:

• receipt_date (required)
• notes
• lines (required, at least 1):
• description (required)
• quantity_received (required, > 0)
• unit_price_cents (required)
• amount_cents (required) – must equal quantity times the locked PO-line unit price, rounded half-up once to cents

Purchase-order picker loading and recovery

The create dialog searches approved and partially received purchase orders on the server with bounded pagination. The two status reads share the exact search authority, so a late result for an older query cannot replace newer options. If one status read fails, its warning names the missing subset while purchase orders from the successful subset remain selectable. Try again repeats the exact failed query and merges recovered options without duplicates. If both reads fail, the required picker and save path remain unavailable. “No approved or partially received purchase orders” appears only after both reads succeed with zero options; a failed subset is never reported as empty.

Post a Goods Receipt

Posting triggers:

1. A GL journal entry: DR Expense / CR GR/IR Clearing (account 2010)
2. Updates each PO line’s received quantity (rejected items are skipped)
3. Transitions the PO status to received (all lines complete) or partially_received

Only draft receipts can be posted. Post requires the visible receipt and purchase-order revisions plus one retry-stable command identity. Keystone revalidates the active tenant-owned PO account, derives the exact receipt value, and commits receipt status, PO quantities/status, GL accrual, revisions, durable command, and audit together. A timeout is outcome-unknown until the exact receipt and PO reload; controls remain locked until reconciled.

Cancel a Goods Receipt

Cancelling a posted receipt:

1. Reverses the GL journal entry
2. Restores PO line received quantities
3. Recalculates the PO status

Cancel uses the same receipt/PO revision and idempotency contract as post. Keystone checks every normalized receipt allocation, not just a representative line. It blocks cancellation when an approved, partially paid, or paid bill depends on the receipt. If only an unapproved match run depends on it, cancellation invalidates that run and the bill must be matched again. A quantity or journal-lineage mismatch fails closed; Keystone never clamps a corrupt negative quantity.

Check Receiving Status

Shows per-line and overall receiving progress: quantity ordered vs received, completion percentage, and whether receiving is complete.

Tenant-Safe Vendor Display and Recovery

Three-Way Matching

Three-way matching validates that three documents agree before approving vendor payment: the purchase order (what was ordered), the goods receipt (what was received), and the vendor invoice/bill (what was billed).

Dashboard and bill-list loading recovery

The exception summary and exception rows load independently. Each filter/query owns its settled result; a failed or late response cannot show an older population under a new filter. If the summary fails, exception rows remain usable and retained summary data is marked unavailable until Try again succeeds; missing cards do not mean zero exceptions. The Run Match bill list uses bounded server search filtered for matching eligibility before pagination. A failed bill read shows the backend detail and blocks the bill selector and Run Match so stale eligibility cannot initiate a financial match. A successful zero response shows the explicit “no bills linked to purchase orders” state. Retrying a read never runs a match or changes financial state. Matching configuration also fails closed: unknown policy is never replaced by plausible defaults or an enabled Save action.

Run Matching

The bill must be linked to a purchase order. The matching engine:

1. locks the exact PO, bill, lines, posted receipts, active run, and policy;
2. correlates ordered, posted-received, and billed quantities using exact decimals;
3. allocates only still-available receipt quantities and records every contributing receipt line;
4. computes ordered-to-received and billed-to-received variance independently;
5. flags missing, unmatched, or out-of-policy rows; and
6. stores an immutable run/result/allocation snapshot.

View Match Results

Returns detailed match results for each line, including:

• Quantity ordered, received, and billed
• Price per unit on PO vs bill
• Price variance (cents and percentage)
• Quantity variance (units and percentage)
• Exception status and escalation level

The current view follows only the bill’s active run. Match history retains immutable native runs and provenance-labeled archived pre-cutover evidence; archived history never authorizes approval. Overall Matched requires the complete PO and bill populations with no missing, unmatched, pending, or rejected result.

Keystone rechecks tenant ownership on the bill, its bill lines, linked purchase-order lines, and every returned match row. A bill ID from another tenant returns Not found. Corrupted or legacy match rows carrying another tenant ID are omitted rather than exposed; operators must not attempt a cross-tenant lookup to explain a missing row.

Handle Exceptions

Match exceptions require review when variances exceed tolerance thresholds.

Approve an exception:

Reject an exception:

Both actions require the visible bill/result revisions and a retry-stable decision key; optional notes are part of that immutable intent. The bill creator cannot approve match exceptions on their own bill (separation of duties). While one decision is in flight, all competing exception actions, filters, and modal dismissal remain locked. An ambiguous response uses the exact exception endpoint; same-key replay remains exact even after another decision advances the bill revision.

Exception Dashboard

List pending exceptions:

Filters by escalation level (0-3) and paginates results. Only shows pending_review exceptions.

Exception summary:

Shows total pending count broken down by escalation level and whether critical-level exceptions exist (levels 2-3).

Exchange Rate Management

Exchange rate management supports multi-currency operations per ASC 830 / IAS 21.

Manage Rates

List rates:

Filters by currency pair. Returns rates ordered by effective date (newest first).

Add a rate:

Fields:

• from_currency (required, 3-character ISO code)
• to_currency (required, 3-character ISO code, must differ from from_currency)
• rate (required, > 0; retained as an exact decimal)
• effective_date (required)
• source – defaults to “manual”

Currency codes are stored uppercase.

Keystone converts foreign journal amounts with exact decimal rates and half-up minor-unit rounding. For a balanced journal containing multiple lines in one foreign currency at one rate, any bounded cent residual is assigned deterministically to the largest line on the deficient balancing side so the functional-currency journal remains balanced. A mixed-rate/mixed-currency journal or caller-supplied functional amounts must balance explicitly; Keystone rejects an imbalance instead of truncating or silently plugging it.

Current Rate Lookup

Looks up the most recent rate effective on or before the given date (defaults to today). Uses inverse fallback – if no USD/EUR rate exists but an EUR/USD rate does, returns 1/rate.

Period-End FX Revaluation

Requires entity-scoped keystone.accounting.close or keystone.accounting.manage permission. The operation is exact-entity and returns its functional currency. Keystone withholds revaluation with a typed unavailable error when profile or journal-line currency evidence is incomplete, or when any open foreign balance requires the missing durable monetary-account classification. It never posts a partial or global revaluation. A complete population with no open foreign balance returns zero in the disclosed functional currency.

The Exchange Rates workspace can be viewed in the context of a selected company. Functional currency pairs only limits the list to market-rate pairs containing that company’s functional currency. Rates remain shared tenant market facts; selecting a company changes relevance and context, not ownership of the underlying rate.

FX Gain/Loss Report

The Exchange Rates workspace uses the validated global company-entity scope. The report lists posted lines to FX Gain (4810) and FX Loss (5986) for that exact entity and inclusive period, including reviewed manual FX adjustments. It requires accounting-view authority for the selected entity; changing entities clears prior evidence rather than showing it under the new scope.

The table is server-paginated. The visible gain, loss, and net cards are explicitly full-population totals from the same query as the current page, not a total reconstructed from the first page. The URL preserves the selected entity, report tab, period, and page for back/forward navigation. A failed same-scope refresh retains the previously successful result with an unavailable warning and retry; a stale or out-of-range response cannot become a false empty report.

Amounts are displayed only when every posted FX line has scoped functional-currency evidence matching the selected entity’s authoritative functional currency. Missing, legacy, or mixed evidence produces an unavailable report with no fabricated zero or USD fallback; a genuinely empty, complete population is shown as zero in the disclosed functional currency.

Bank Feed Connections

Bank feeds automate transaction import into the reconciliation system. Three connection types are supported:

Type	Use Case	Import Method
plaid	First-party provider	Automated sync with cursor
manual_import	File upload	CSV/OFX via bank import
api_push	External systems	Batch ingest endpoint

Create a Bank Feed

Fields:

• name (required)
• institution_name (required)
• account_number_masked – display reference
• sync_frequency_hours – how often to auto-sync (default 24, range 1-720)
• config_data – connection-specific configuration

Plaid feeds start in pending_auth status and must complete authorization before syncing. Manual and API push feeds are immediately active.

Authorize a Provider Feed (Plaid)

Completes the OAuth flow for a provider feed. Optionally accepts seed transactions for initial data. After authorization, the feed transitions to active with pending_initial_sync state.

Sync a Provider Feed

Runs a manual sync for a Plaid feed using a durable cursor. Each sync only imports transactions not previously seen. Handles:

• Transient failures: Automatically schedules retries with exponential backoff (15min, 60min, 240min)

Automated Sync Scheduling

Provider feeds sync automatically based on their sync_frequency_hours setting. The scheduler checks each feed independently per tenant. Feeds in error/retry state respect their backoff windows.

Manage Feed Connections

Bank Reconciliation

Collections Recovery

Use Manage Collection from an overdue invoice to continue in the Finance collections workspace. That workspace shows the customer and failure context and provides resolve, reschedule, and policy-based escalation actions. Write-off remains a separate bad-debt decision; it is not the default collections action.

Close Run Status

AR Management – Bad Debt and CECL

Write Off an Uncollectible Invoice

Two write-off methods:

Method	GL Entry	When to Use
direct	DR Bad Debt Expense (5970) / CR AR (1200)	Small companies, immaterial amounts
allowance	DR Allowance for Doubtful (1210) / CR AR (1200)	When CECL allowance already established

Only an operator with both finance-management and accounting-management authority can request a write-off. Select the visible write-off date explicitly; it must be on or after invoice issuance and in an open fiscal period for the invoice’s exact company entity. Submitting creates an approval request, not a journal entry or receivable reduction.

CECL Bad Debt Estimate (Preview)

Preview the expected credit loss estimate without posting any entries. Select one exact company entity. The preview uses the same as-of open-AR events and bucket boundaries as AR Aging, reads that entity’s Allowance for Doubtful Accounts balance, and displays its invoice_receivable_events basis plus per-bucket half-up minor-unit rounding policy. A failed refresh retains the prior verified preview with an explicit warning; it is not relabeled current.

• rate_current – loss rate for current (not yet due) invoices
• rate_1_30 – loss rate for 1-30 days past due
• rate_31_60 – loss rate for 31-60 days past due
• rate_61_90 – loss rate for 61-90 days past due
• rate_over_90 – loss rate for 90+ days past due

Rates are decimals between 0 and 1. Keystone multiplies each bucket by its exact decimal rate, rounds that bucket half-up to a whole minor unit, and then sums the bucket losses. A missing allowance account, unavailable pre-cutover AR history, or missing entity scope blocks the preview; none of those conditions is treated as a zero.

The actual CECL adjustment is posted only through the monthly close approval process (step 4e). The journal identifies the approving close run; a replay returns that same financial decision, while changed evidence under the same decision is rejected.

The close-run detail keeps the scenario maker’s latest review identity, time, and note separate from the distinct approver’s identity, time, and reason. Approval does not relabel the maker’s review as the approver’s work; both decisions remain visible and attributable in the audit record.

When a completed close run’s CECL adjustment must be recalculated, Keystone reverses the original entry and values the replacement against the closed period-end data and the allowance baseline captured by that close run. Reverse and recalculate actions show the posting authority before confirmation: the earliest later open fiscal period for the same company entity and the first day of that period. The resulting journal, operator action, and checklist journal evidence display that same date and period. The frozen package for the closed period remains unchanged.

The operator who posted the CECL journal, created the close run, reviewed the CECL scenario, or approved the close cannot also reverse or recalculate it when another tenant-wide close operator is available. Keystone denies the action before any financial mutation and retains the denial in the SoD audit trail. A distinct close operator must perform the remediation. For a tenant with only one active tenant-wide operator holding close permission, Keystone uses its existing single-operator control exception; both the exception and the completed remediation are durably audited. There is no separate CECL override switch.

Keystone compares these actors by their canonical Portal user IDs. The internal local user-row number is retained separately for audit storage and cannot create a match, denial, or single-operator exception when it happens to equal a different person’s Portal user ID. Keystone writes both identity namespaces before sealing the immutable success audit, so the stored record hash and tenant audit chain cover the same actor evidence operators review.

If the workspace cannot find a later open period for the entity, it hides the remediation actions and links to fiscal-period setup. The API independently enforces the same rule. Create or reopen the appropriate later period, return to the close run, and retry. Keystone never posts the correction to the closed source period, another entity’s period, or an ambiguous current date.

Fixed Assets

Track capitalized assets, compute depreciation, handle disposals, and record impairment losses per ASC 360-10 / IAS 16.

The workspace follows the validated global company-entity selector. A new asset freezes the exact default-profile identity, supported functional currency, and profile checksum at creation; the API never accepts a client currency. Existing historical assets without that provenance remain visible as currency unavailable, but their cents are not reformatted, summed, edited, impaired, disposed, or depreciated. A current profile that is missing, invalid, or conflicts with an asset’s frozen currency has the same unavailable truth. Keystone does not assume dollars: missing authority disables creation and lifecycle actions without turning the register into an empty or zero state. Changing entities clears prior-entity amounts while the new scoped request is in flight. The register is server-paginated. Its pager count covers the complete filtered population; cost and monthly-depreciation summary cards are explicitly limited to the visible page. If filters or concurrent changes make a page invalid, Keystone returns to the last valid page and reloads it instead of claiming that the register is empty.

Create a Fixed Asset

Fields:

• name (required)
• asset_number (required, unique per tenant)
• description
• category – for grouping (e.g., “Computer Equipment”, “Furniture”)
• acquisition_date (required)
• acquisition_cost_cents (required, > 0)
• salvage_value_cents (default 0, must be < acquisition cost)
• useful_life_months (required, > 0)

The system auto-computes depreciable_base_cents (cost - salvage) and monthly_depreciation_cents. Every new asset is assigned to one legal entity. The monthly close sends that same tenant/entity scope to depreciation; it never sweeps all tenant assets. The API locks the permission-checked entity’s canonical default profile and freezes its supported functional currency, profile identity/version, and canonical checksum before submission. Lifecycle posting locks the asset again and verifies that the current canonical profile still has the same identity and functional currency; it does not reinterpret cents using a later profile. The change while scoped assets exist. Acquisition and salvage inputs show the derived currency before submission, and every returned monetary response repeats the frozen currency only when its authority is available. Historical assets without the complete evidence remain read-only. A tenant accounting manager can inspect the bounded Legacy asset recovery queue, which states that Accounting Support owns retained-evidence resolution; the queue is audit-only and never invents entity, currency, or posting authority. They are never silently relabelled. Monthly amounts use exact cents: the final useful-life period receives the deterministic remaining-basis true-up without going below salvage value.

Asset Lifecycle

Dispose of an Asset

Fields:

• proceeds_cents (default 0) – sale proceeds
• disposal_date (default today)

The system posts a GL entry that:

1. Removes the asset cost from the asset account
2. Removes accumulated depreciation
3. Records any sale proceeds
4. Recognizes gain or loss (proceeds minus net book value)

Accumulated depreciation is read in the exact tenant, entity, asset, and disposal-date scope. It includes posted impairment evidence and excludes reversed evidence, so another tenant’s colliding asset ID cannot change net book value. Disposal locks and revalidates the frozen asset/profile currency authority before creating the journal; unavailable legacy or drifted evidence returns a recovery error and posts nothing.

Create, disposal, and impairment retain one idempotency key across a timeout retry. A same-key/same-command retry returns the original asset or journal result without a second audit or journal; a changed command under the same key is rejected. General journal reversal is deliberately unavailable for asset depreciation, impairment, and disposal entries until Keystone provides an atomic asset-reversal workflow.

Record an Impairment Loss

Fields:

• fair_value_cents (required) – must be less than the carrying amount
• reason (required)

Impairment loss = carrying amount - fair value. Posts GL entry: DR Impairment Loss (5980) / CR Accumulated Depreciation (1520). Cannot impair disposed or fully depreciated assets. The workspace’s impairment action labels fair value and the resulting loss in the asset’s authoritative functional currency. It retains the entered evidence and reason after a recoverable failure so the operator can correct or retry; the server re-reads current carrying value and rejects a value that does not produce a loss.

Depreciation During Close

Monthly depreciation is automatically computed and posted during the close process (step 3: run_depreciation). Before deriving each asset’s journal lines, the worker locks and revalidates its frozen profile/currency evidence. An unavailable legacy or drifted asset is reported as a failed recovery item and posts no journal; it is not recast using the current profile.

Financial Obligations and Compliance Calendar

Track regulatory and tax compliance deadlines with a generated obligation calendar.

Generate Obligations

Fields:

• tax_year (required, 2020-2100)

Generates approximately 19 standard obligations for the year, covering:

• Quarterly estimated tax payments (Q1-Q4 with IRS due dates)
• Monthly close runs (Jan-Dec)
• Annual tax filing
• 1099 vendor reporting
• Year-end close

The operation is idempotent – calling it again for the same year does not create duplicates.

Manage Obligations

The obligation editor searches close runs by period, run type, status, or run number. Choices are limited to the obligation’s company entity, and the backend rejects a link to another entity or tenant. The current selection remains visible while searching and can be cleared. Group-scoped obligations cannot link an entity-owned close run.

Obligation Statuses

Obligations move through these statuses:

• scheduled – generated but not started
• in_progress – work underway
• ready_for_review – pending final review
• completed – done (auto-sets completed_at timestamp)
• blocked – requires resolution
• overdue – past due date

Annual Reporting Package

Generate a CPA-ready annual reporting package for tax filing and audit.

Generate Package

Fields:

• tax_year (required, 2020-2100)
• force (default false) – bypass stale tax table check

Send a stable Idempotency-Key when retrying after a timeout. The same key and unchanged entity/year/force command returns the existing artifact; changing the command requires a new key.

Retrieve Package

Both endpoints return the same package containing:

• Year-end trial balance – all accounts with debit/credit totals
• Income statement – full P&L for the year
• Balance sheet – as of year-end
• Deduction schedule – tax-deductible expenses by category
• Depreciation schedule – all fixed assets with depreciation details
• Tax payment ledger – quarterly estimated payments made
• Vendor 1099 candidates – vendors meeting the reporting threshold
• K-1 summary – LLC member profit allocation and distributions
• Evidence links – references to supporting documents
• Failed sections – any sections that errored (other sections still generate)

The package is exact-entity, exact-functional-currency evidence. It freezes the selected entity’s default-profile fingerprint and does not convert transactions with live FX. A changed or unavailable current profile leaves the historical artifact readable/exportable with its recorded evidence, but blocks filing until regeneration. Old tenant-wide artifacts are labelled unavailable rather than silently assigned to an entity. The package runs a freshness check against tax tables; stale tables block generation unless force=true.

Operator workflow

Use one Generate action for a given entity/year/force choice. Keystone keeps its idempotency key through a timeout or other unknown outcome; use Retry to recover the same command. Changing entity, tax year, or force is a material edit and creates a new key. A historical profile mismatch remains readable and exportable as frozen evidence, but filing is unavailable until the package is regenerated against the current entity profile.

When a history row is focused, its export calls the exact artifact endpoint rather than substituting the current package for that tax year. The download audit and response headers identify the focused artifact, content hash, entity, profile fingerprint, and functional currency.

Tax Brackets

Manage federal and jurisdictional tax bracket sets used for quarterly estimates and annual reporting.

List Bracket Sets

Create a Bracket Set

Fields:

• name (required, e.g., “2026 Federal Income Tax”)
• tax_year (required, 2020-2100)
• jurisdiction (default “US_FEDERAL”)
• effective_date (required)
• expiry_date (optional)
• bracket_data (required) – array of brackets:
• upper_bound_cents – strictly ascending, last must be >= 10,000,000,000
• rate – between 0 and 1

Bracket upper bounds use the standard currency control. Values are displayed as dollars and cents and retained as integer cents for validation and submission, including the required catch-all threshold.

• se_tax_rate – self-employment tax rate
• se_deduction_factor – SE deduction factor
• corp_tax_rate – corporate tax rate
• fica_rate – FICA rate
• source – where the rates came from
• notes

Check Bracket Staleness

Returns whether the current bracket set is stale or missing, with a reason and the linked bracket set details.

Tax Table Status Dashboard

Shows status of all tax tables for the current and next year:

• Federal brackets: loaded status and source
• FICA parameters: SS rate, SE tax rate
• Sales tax rates: stale count, states without rates
• action_required: true if any tables need attention

Quarterly Tax Estimates

Compute estimated quarterly taxes from GL data and record tax payments.

Compute an Estimate

Fields:

• tax_year (required, 2020-2099)
• quarter (required, 1-4)

Keystone uses the tenant’s active default entity. The system isolates quarter and YTD GL data, prior-year safe-harbor tax, and prior-quarter payments to that entity, then applies its tax profile and bracket tables. Omission is not a consolidated or all-entity calculation; compute each entity separately to preserve one auditable estimate per entity, year, and quarter. The estimate includes:

• Gross income
• Total deductions
• Net taxable income
• Income tax
• Self-employment tax (for sole props and LLCs)
• Total estimated tax

Company profile must be configured first. Recomputing the same entity, tax year, and quarter updates that entity’s existing estimate; it does not overwrite another entity’s estimate. The

Record a Payment

Fields:

• amount_cents (required, > 0)
• payment_date (required)
• payment_method (required)

List Estimates

active company entity within your tenant.

Tax Reporting and Filing

Entity-Aware Tax Summary

Shows a complete tax summary based on the company’s entity type (sole proprietorship, LLC, S-Corp, C-Corp, partnership). Automatically detects entity type from the company profile. For S-Corps, accepts officer_salary_cents for reasonable compensation calculation. For partnerships and multi-member LLCs, includes per-member profit allocation based on active member count.

Preview

Lists all vendors with their total payments for the year. Flags vendors that meet the IRS 1099-NEC threshold (currently $600). Aggregates both expense payments and bill payments. C-Corp and S-Corp vendors are automatically exempt. Vendors missing W-9 or marked ineligible are flagged with blocking reasons.

Generation

Generates 1099-NEC data for eligible vendors. Blocked if tax tables are stale (use force=true to override with audit logging). Tax IDs are masked by default – pass include_full_tin=true with appropriate permissions for unmasked values.

Generation and its audit evidence commit before Keystone reports success. A forced freshness override shares that transaction. If audit persistence fails, correct the audit dependency and retry; Keystone does not report an unaudited generation as successful. The reconciliation action follows the same audit rule.

Returns:

• vendors – eligible, unblocked vendors ready for filing
• blocked_vendors – vendors that meet the threshold but have blocking issues (missing W-9, marked ineligible)

Filing Readiness

A comprehensive pre-filing checklist that verifies:

1. Company tax profile is configured
2. Tax tables are current and not stale
3. All fiscal periods for the year are closed
4. Compliance calendar obligations are complete
5. 1099 vendor reviews are clear

Returns an overall status (ready / attention_needed / blocked) with a detailed checklist and next deadline. The annual-obligation summary also identifies its population as not generated, incomplete, or complete. A missing or partial population is shown as unavailable/incomplete with the missing count; it is never presented as Clear, 0 overdue, or 0 blocked merely because no rows exist.

The tax_year in the Tax Reporting URL is shared by Filing Readiness, Entity Summary, 1099 Preview, and Generate 1099s. Switching tabs preserves that year. A failed read keeps the selected year beside a retry action, and a late response for an older year cannot replace the current view.

Filing Completion and Transport

Record the handoff of annual filing completion and the direct filing transport. These endpoints maintain an auditable record on the annual filing obligation, tracking submission status, retry handling, and recovery state. Both store a full readiness snapshot at the time of recording.

Filing completion must be recorded before filing transport. Both require the annual filing obligation to be generated first. The completion form never defaults to Completed: select an outcome explicitly. Completed and Recovered remain unavailable until readiness is clean; Blocked and Retry scheduled remain available after the obligation exists so an attempted handoff can retain truthful recovery evidence. Filing controls and tax-year selection are locked while a handoff or transport request is in flight. Changing the selected company externally or changing tax year afterward clears unsent evidence; if an old-scope request then reaches a terminal result, Keystone identifies the exact original entity/year outcome without replacing the current view. A completed handoff or any recorded transport locks the completion controls, while a recoverable same-scope API failure keeps the entered evidence in place for retry.

Each action locks the exact tenant/entity/year obligation and commits its state with before/after audit evidence. An identical retry returns the existing timestamped result without another audit row. Conflicting replacement of a completed handoff or completed transport returns a conflict, and completion evidence cannot change after transport evidence exists. Audit failure preserves the prior state. The transport form records observed evidence; it does not itself transmit a filing to an external provider.

When a close run blocks for a CECL allowance review, a distinct approver can approve the previewed adjustment. Keystone posts the approved allowance entry, refreshes the statement package, and closes the period in the same controlled close transaction.

Purchase-order account selection searches active accounts by number and name. Typing an exact displayed value and pressing Enter commits the option; no mouse-only selection step is required.

When creating a purchase order, select a vendor, enter a PO number, and complete the description, positive quantity and price, and accounting account for every line. Missing requirements stay highlighted in the dialog and no draft is created. Operators with vendor-management permission can use Create vendor beside the vendor search; Keystone creates the minimal vendor record, selects it, and keeps the purchase order work in place.

The tenant accounting baseline includes account 5750 — Office Supplies & Expenses, so a new tenant can code an ordinary office purchase order without first extending its chart. The searchable account control also commits the only remaining filtered result when Enter is pressed.

Invoices with an explicit multi-day service period, and subscription invoices with a multi-day billing period, create deferred-revenue schedules. Revenue is released over the service period instead of being recognized in full when the invoice is sent. One-time invoices that merely carry billing dates remain immediate revenue unless an explicit service period is present. Deferred posting requires at least one invoice line so every schedule has durable source-line evidence; malformed header-only deferred invoices fail before GL posting.

Close runs that encounter an unexpected transaction failure are rolled back and then marked failed in a fresh transaction with scheduler audit evidence. Operators should correct the reported failure, cancel the failed run, and create a replacement; a failed execution must not remain indefinitely in running.

Controlled accounting migration

Use Financials → Accounting → Controlled accounting migration only when converting one legal entity’s opening balances. Select the company first; the workspace does not infer an entity from the source file. You need accounting view permission to inspect evidence and accounting manage permission for the selected entity to stage or commit it.

1. Record the source system, export ID/version, conversion date, source CSV, and a stable idempotency key. Keystone displays the selected company’s functional currency from its active default profile; it is read-only, and a missing profile blocks manifest creation instead of defaulting to USD. Choose Balanced trial balance only when source debits and credits tie exactly. Choose Explicit Opening Balance Equity only for a known conversion residual, then select the displayed active classified system equity account for this entity. Keystone saves the exact mode/account fingerprint; it never guesses an OBE account from a number. Keep the idempotency key when a network outcome is unknown; it is the safe retry identity.

2. Stage the required master-data batch and the source trial balance in integer cents. Correct a rejected file rather than treating an empty history or unavailable result as success.

3. Map source accounts, submit a dry run, and read the server-recorded source and target totals plus every variance. In explicit OBE mode, include the separately disclosed exact OBE residual in the target trial balance; it is not an imported source variance. Only Matched evidence can advance to the final action.

4. Choose Commit opening balance, review the confirmation, and submit it. Keystone rechecks the open period, account/currency scope, mapping, and current ledger before posting one immutable journal. It may reject a stale dry run even if the screen previously showed matched.

For a generic CSV conversion, declare only the artifacts that are actually in the source (chart of accounts is required; customers, vendors, products, open AR, and open AP are optional with an explicit absence reason). Upload one CSV for each declared artifact, enter its source identity column and mapping, then record the artifact dry run. Review the server-paginated artifact status and immutable source-to-target lineage before choosing Apply ready artifacts; the confirmation does not bypass server revalidation. A failed, unavailable, or empty evidence page is not proof that the conversion finished.

Migrated opening receivables/payables are labelled Migrated opening item. Their remaining balance comes from immutable settlement events. For AR, choose only an eligible customer payment or customer credit; Keystone creates the payment as pending and marks it complete only with the application and balanced journal. For AP, use the dedicated migration vendor-payment form and select an active scoped cash or clearing account; do not select an ordinary BillPayment. Keep the retained amount/reference/date input when a known validation failure is shown. For an unknown outcome, refresh the same migration job and its item events before retrying—never submit a second payment because the page was slow.

If the conversion needs historical fiscal periods, enter the bounded number of prior months and choose Preview periods. Review every existing/open period and its fiscal-year label before Apply safe periods. Keystone creates only missing open months and preserves all existing states. A closed/locked continuity warning is a stop condition: resolve the fiscal calendar with an authorized accountant rather than trying to reopen periods through migration.

If a request times out, loses its connection, or returns an unavailable server outcome, do not submit a new job. Refresh the same job from Migration history and inspect its immutable variance/journal evidence. Validation, permission, and conflict messages are known failures: correct the retained input rather than treating them as unknown. A committed job provides a scoped View linked journal action; a replay returns that exact journal rather than posting again. Missing evidence, mismatches, or a permission denial require the stated correction or an authorized operator; none is a clean or complete conversion.

Tenant-scoped company profiles

Accounting settings are always resolved inside the signed-in tenant and selected company. Keystone does not fall back to another tenant’s default profile when company context is missing. Recurring accrual templates can use only accounts from the current tenant’s chart of accounts. A missing or foreign account is rejected before the template is saved, and close runs never load another tenant’s template. Only one active close run can exist for a company period. If a run is already pending, running, or blocked, resolve or cancel it before starting another.

Work queue

Open Work queue at the relevant workflow to review bookkeeper exceptions across banking, expenses, communication capture, three-way matching, and bill approvals. The queue follows the validated company in the global authority bar; tenant-wide or authority-unresolved work is labelled separately. Choose My work or Team work, optionally select a work kind, and use the server-backed pager. Assignment, shared-pool, and read-only labels explain whether you can act or only inspect. Filters remain in the URL for refresh and back/forward navigation. Open source takes you to the exact entity-scoped source record. If a source is restricted or unavailable, Keystone says so and keeps previously loaded rows visible; retry that source instead of treating it as an empty or cleared queue.

Vendor memos

Open Vendor memos after choosing the legal entity in the workspace bar. Choose Request vendor memo, select the displayed source Bill, then select only the posted-journal lines Keystone shows. Enter the exact whole-cent amount for each selected line and mark tax only when the line permits it. Attach the vendor document and enter its reference and effective date. The form keeps your input when Keystone reports a stale source, permission denial, or unavailable service; refresh the source evidence before resubmitting a stale request. Keystone uploads the selected vendor document first and freezes its durable document identity, exact vendor-attachment identity, entity scope, checksum, filename, type, and size in the command. If the memo request then fails, the uploaded document remains recoverable in Documents and the retry reuses it; do not upload a replacement merely to retry an unknown result. One vendor document is immutable financial evidence for only one AP workflow and entity: it cannot be reused later for a different memo or vendor statement.

Request independent approval records a pending command—it does not post a journal or change AP. An independent approver uses the Financial approval queue for the same entity. After issuance, open the memo’s evidence view to inspect the immutable journal-linked event history and remaining balance. To apply an issued memo, use the searchable Bill picker, enter an exact whole-cent amount, and request approval. Do not create a manual journal for that application: a finalized application consumes the retained subledger memo credit without a second posting. For failed, stale, or unknown outcomes, refresh the same memo and follow its queue recovery state before creating another command.

Vendor statements

Open Vendor statements at the relevant workflow after selecting the legal entity. Choose the vendor, enter the statement reference, currency, period, and signed opening and closing balances. Upload the vendor’s CSV statement and map the four displayed headers. Keystone does not parse PDF or image statements; the form reports that format as unavailable rather than claiming an OCR result.

The document uploads first and remains attached to the selected vendor in Documents. If storage succeeds but the import request times out, fails, or is unavailable, do not upload it again: keep the displayed input and retry the same request so Keystone reuses its idempotency key and retained evidence. Open the exact statement from History, match each displayed statement line to a server-paged payable event, or provide an exact exception code and reason. Candidate events cannot be reused. When every line is prepared, select Freeze reconciliation plan, then Request independent approval. Neither action posts a journal or settles a bill. The freeze command retains one key over an unknown timeout: retrying unchanged selections returns the same frozen hash; changing a selection requires a fresh command. Before freezing, Keystone locks and rechecks the exact vendor attachment, active entity/vendor, checksum, and document metadata.

An independent approver acts from the entity’s Financial approval queue. Use the statement evidence history and status for recovery. If source evidence is stale, revoked, unavailable, or an execution result is unknown, refresh the same statement and follow the displayed recovery state; do not create a manual journal or a duplicate statement.

Bill capture

Open Bill capture at the relevant workflow after selecting the legal entity. Choose the vendor and currency first, then either upload one PDF, JPEG, or PNG invoice document or select a server-paged retained vendor document. A retained document must already be attached to that exact vendor and must match the selected entity and vendor currency. Keystone freezes the exact attachment, checksum, file metadata, entity, vendor, and currency on the capture record before recording the capture. If the capture request times out, fails, or has an unknown result, the uploaded evidence remains in Documents: retain the form input and retry the same request instead of uploading a duplicate. A document already captured is not offered for reuse.

Extraction is a bounded review aid, not an accounting decision. A missing PDF text parser, OCR dependency, unsupported file, or unreadable document is shown as Extraction unavailable. Review or enter the invoice number, dates, tax, and one or more bounded manual line rows. Each row needs its own description, exact whole-cent amount, and active expense account before selecting Create draft bill. This action creates only a normal draft Bill; it does not request approval, post a journal, or move AP. Open the resulting Bill and use the existing independent approval workflow. Draft creation retries the same capture safely and preserves its linked document evidence.

AP payment runs

The currency shown in AP payment runs, vendor memos, vendor statements, and bill capture comes from the selected entity’s Company Profile and is not an editable USD default. If it is unavailable, complete the entity profile before starting a command. A legacy item labeled as lacking currency authority remains available for audit but cannot continue; create a new correctly scoped command from current evidence rather than relabeling the old item. If a non-USD entity has no compatible provider destination, use a supported manual workflow or resolve provider capability—Keystone will not submit a USD-labeled payment. Treat an unavailable AP aging/export as a currency-evidence exception, not as zero, and correct the underlying legacy/mixed evidence before relying on totals.

Open AP payment runs after selecting the legal entity in the workspace bar. Search the server-paged payable Bill directory rather than relying on a loaded first page. Selecting a Bill defaults the amount to its current outstanding balance; enter a smaller exact whole-cent amount only for an intentional partial payment, then choose the effective date. For a manual line, search the server-paged active settlement-account directory. The account directory is tenant-wide for lookup convenience; the server revalidates the selected account against the payment run’s exact entity before posting. Keystone records the payment evidence only after independent approval. For a Mercury line, choose only a displayed ready destination; Keystone does not display or accept bank details, recipient IDs, or provider credentials here. If no provider destination is listed, resolve the vendor/provider configuration or choose manual fulfillment.

Choose Preview selection first. It validates current Bill, vendor, entity, currency, and provider facts but does not move money. Create payment run stores the immutable selection, after which Request approval sends the same entity-scoped command to the Financial approval queue. An independent operator records the decision there. Approval may queue a Mercury instruction, but it is not a provider-confirmation claim.

Use the run history and its server-paginated line evidence for recovery. A manual line in Manual fulfillment ready can be recorded with its canonical bill payment and linked journal. Queued, Submitting, and Submitted provider lines need no duplicate action. Provider outcome unknown, Failed, or Blocked requires the stated bill-payment recovery action and a refresh of the same line; do not create another payment run or instruction. If a request outcome is unknown, refresh history before retrying so the durable idempotency and audit evidence remain authoritative.

Financial statement currency evidence

P&L, balance sheet, cash flow, and general-ledger views are always for the selected legal entity. The response identifies the functional currency, status, and population basis. A configured entity with no posted activity may show a known zero; missing, legacy, or mixed journal evidence shows Unavailable and must not be interpreted as zero. General-ledger status is proved over the full filtered population, not only the visible page.

Detailed close packages use schema v4 and freeze the currency and statement basis at completion. v1-v3 historical packages remain available for control evidence, but their detailed monetary statements are legacy-unavailable; do not infer a current profile currency. Resolve the entity’s functional-currency evidence and regenerate the close package before using detailed published figures.

Bank reconciliation currency evidence

Start reconciliation from the selected legal entity. Keystone freezes the entity’s supported functional currency and profile evidence for the statement, GL balance, difference, two-column view, and export. A legacy or incomplete session is still discoverable for audit, but its money is shown as unavailable and it cannot be completed or exported as monetary evidence. Repair the entity profile or create a new scoped reconciliation; never treat unavailable as zero or relabel transaction cents as the functional currency.