Institutional Export Formats

CommunityPay provides standardized institutional exports designed for consumption by external validators — CPAs, insurance underwriters, and escrow officers. Each export type delivers a structured JSON document with versioned schema, comprehensive metadata, and cryptographic verification.

This page describes the three export types, their schemas, and the verification model.

Export Architecture

All institutional exports share a common architecture:

Base Structure

Every export produces an ExportResult containing:

{
  "success": true,
  "export_type": "AUDIT_READINESS",
  "data": { ... },       // Export-specific content
  "metadata": { ... },   // Standard metadata
  "errors": [],           // Any errors encountered
  "warnings": []          // Non-fatal warnings
}

Standard Metadata

Every export includes ExportMetadata:

The content_hash enables independent verification: any party with the data can recompute the hash and confirm the export has not been modified.

Export Type 1: Audit Readiness

Type: AUDIT_READINESS Schema version: 1.3 Consumer: CPAs and external auditors performing annual audits Scope: One fiscal year

Contents

Association Identity

• Legal name, EIN, address, total units, fiscal year end month

Financial Statements

• Balance sheet at period end: total assets, total liabilities, total equity, a balanced flag, assets and liabilities by category
• Income statement for the period: total revenue, total expenses, net income, revenue and expenses by category, and the basis it is stated on

Fund Balances

• Per fund: name, type, balance, as-of date, whether it is restricted, and the restriction's purpose

Journal Entry Summary

• Total entries, total debits and credits, a balanced flag
• Entries by type and monthly totals
• A statement that posted entries are append-only

Approval Audit Trail

• Total approval requests, approved, rejected, and pending, and the approval rate
• A sample of high-value approvals with their approval levels

Internal Controls

• Eligibility evaluations in the period by result: eligible, ineligible, conditional, excluded, withheld, and errored
• Transactions passed and blocked, and a control-effectiveness measure where one was measured

Reconciliation Status

• Reconciliations in the period, the latest one, and whether every month in the period was reconciled

Audit Notes

• Four fixed statements about the export, followed by any warnings raised while the export was built

Sections built from measured data carry a measurement status and a note, so a figure that was not measured is labelled and is not presented as zero.

Use Case

A CPA preparing for an annual audit requests an AUDIT_READINESS export. The export provides fund-segregated financial statements, a journal entry summary, approval records, and control documentation in a machine-parseable format. The CPA can import the data into audit workpapers and verify the content hash. For entry-level detail, the whole-books export below carries every journal entry with its enforcement decision id.

Export Type 2: Controls Risk Snapshot

Type: CONTROLS_RISK_SNAPSHOT Schema version: 1.1 Consumer: Insurance underwriters assessing risk Scope: A lookback period, twelve months by default

Contents

Risk Summary

• Risk tier and coefficient, with the factors that contributed, when they were measured

Eligibility Evaluation History

• Evaluations in the period by result, the eligibility rate, and a monthly trend

Exclusion Trends

• Exclusions created in the period and currently active, by severity and by trigger, and the resolution rate

Vendor Compliance

• Total vendors, vendors linked to a licensing record, compliant vendors, the compliance rate, and active alerts by type

Governance Metrics

• Items tracked, measured, and breached, the compliance rate, and average resolution time in hours

Dispute History

• Always reported as not measured. No dispute or claims record is kept in the system, so the counts are null and the block says so; a null is the absence of a record, not a statement that there are no disputes

Underwriting Signals

• A list of signals, each with a value and a weight

Each section reports a measurement status. A section with nothing to measure says so.

Use Case

An insurance underwriter evaluating a D&O risk profile requests a CONTROLS_RISK_SNAPSHOT export. The export quantifies exclusions, evaluations, vendor compliance, and governance activity from production data, not from a self-reported questionnaire.

Export Type 3: Escrow Disclosure

Type: ESCROW_DISCLOSURE Schema version: 1.0 Consumer: Escrow officers and title companies processing unit sales Scope: The association, and one unit when a unit is named

Contents

Association Financials

• Total assets, total liabilities, fund balance, cash on hand, accounts receivable, and the delinquency rate

Governance Summary

• Board member count, and whether insurance and the reserve study are current. Whether the annual meeting was held and whether governing documents are on file are withheld (null, with a note), because the system records neither

Insurance Coverage

• Each policy: type, carrier, policy number, liability limit, and expiration

Reserve Status

• Study date, percent funded, funding plan, appraiser, and the next study due

Vendor Compliance

• Vendors with compliance tracking, compliant vendors, and the compliance rate

Pending Litigation

• Matters on record, whether any affects safety or soundness, and the amount claimed

Special Assessments

• Each assessment: name, purpose, total amount, status, and start date

Unit Disclosure and Certification (when a unit is named)

• Unit identifier, owner, dues amount, outstanding balance, whether the unit is current, and the special assessment balance
• Who certified the disclosure, when, and the statement they certified

Use Case

An escrow officer processing a unit sale requests an ESCROW_DISCLOSURE export. The export provides the unit's balance and the association's financial and governance status in a format the title company can process. The content hash verifies that the data has not been modified between generation and the closing.

Whole-Books Export (CSV)

The three JSON exports above are institutional packets: shaped for a CPA's import script, an underwriter's model, an escrow officer's file. The whole-books export is the other half of the same posture — the exit. An association can take every record and leave at any time.

From Reports, Books Export returns one zip. The scope is chosen before the download — a fiscal year, an arbitrary window, or the whole book through a date, and optionally one fund — and every file in the zip honours it.

Nothing inside the scope is filtered. Corrections appear as reversal entries linked to what they reverse, never as edits. A file that cannot be produced for the requested scope is named in the manifest with the reason rather than quietly written full-book: under a fund scope that is the agings and the subledger schedules, which agree to role balances that are not scoped by fund.

The manifest makes the zip self-verifying with standard tools and no CommunityPay code: recompute each file's SHA-256 and compare with the line for it, then shasum -a 256 -c manifest.sha256. That last digest identifies the whole delivery, because the manifest carries the hash of every other file. No owner, resident, board member, or account signatory is named anywhere in the export, and neither is the person who produced it — the manifest records a user number. The same permission that gates report exports gates this one.

Other Institutional Documents

The JSON exports and the whole-books zip are part of a larger set. These documents also leave the system:

• The annual financial statement package: the statements and the notes to them, with a manifest of hashes, checked by the report verification harness before it is shown.
• The prepared-by-client bundle in the CPA audit portal: the subledger schedules an auditor requests by name, read-only and scoped to the engagement period.
• The board packet, in the treasurer's order: balance sheet by fund, budget against actual, delinquency, and reserves.
• The lender and insurer fact layer: the Fannie Mae Form 1076 and Freddie Mac Form 476 questionnaires fill from recorded facts and the ledger. They are generated on request and are not hashed or versioned files.
• Institutional packets: 10 packet types in all, each with a SHA-256 content hash.

Verification Model

All three export types use the same verification model as Evidence Packs:

1. Generate: The export service builds the data payload and metadata
2. Hash: SHA-256 is computed from canonical JSON of the data payload (sorted keys, minimal separators, no ASCII escaping, UTF-8 encoded)
3. Include: The content_hash is stored in the metadata alongside the data
4. Verify: Any recipient can recompute the hash and compare to the stored content_hash

Verification does not require API access, credentials, or trust in CommunityPay. It requires only the data and a SHA-256 implementation.

Schema Versioning

Each export names its schema version in its metadata. A consumer reads schema_version to check which shape of the document it received.

What These Exports Enable

Institutional exports transform CommunityPay from a closed system into an integration point:

1. Audit readiness becomes exportable — CPAs receive machine-parseable data instead of PDFs and spreadsheets
2. Underwriting becomes data-driven — Insurers assess risk from production data, not questionnaires
3. Closings become faster — Escrow officers receive structured disclosures instead of manually assembled packages
4. Verification is independent — Recipients verify data integrity without trusting the source system
5. Integration is standardized — A named schema version in every export lets automated pipelines check the shape they receive

CARI Integration

CARI reports — Lender Report, Insurer Report, Title Report, and Buyer Report — are institutional packets, with the same SHA-256 content hashing, version chaining, and PDF rendering as other packets. They are generated and delivered as packets, not through the JSON export classes above. They are built for external consumers who subscribe to an association's CARI score. Each report type surfaces the sub-score components and underlying signals most relevant to that consumer's decision context.

For published methodology and component weights, see CARI Methodology and Scoring Framework.

This describe