> ## Documentation Index > Fetch the complete documentation index at: https://docs.myfundingmachine.com/llms.txt > Use this file to discover all available pages before exploring further. # Revenue reconciliation > Reconcile Funding Machine collections, refunds, dispute movements and fees across billing accounts. Open **Admin → Internal Ops → Revenue Reconciliation**. This workspace brings the approved Funding Machine activity from the older billing account and all activity from the newer billing account into a cash report. It compares their payments with the Operations CRM and is restricted to verified administrators. The report always opens the Operations Location automatically; the admin Location switcher and the launching CRM Location do not change its reporting scope. ## Approve the older account’s Funding Machine sources Open **Sources & coverage** before refreshing the older account. Its source policy is **Approved Funding Machine only**. The newer account’s source policy is **All transactions**. Approve an exact Stripe **subscription ID** or **charge ID**, choose **FM owner** or **FM usage**, and provide a label and approval reason. A subscription target includes its associated Funding Machine charges and their refund and dispute cash movements. A charge target includes that exact charge and its related movements. Customer-wide inclusion is not supported: sharing a customer does not prove that another product’s payments belong to Funding Machine. A reviewed target registry can also be imported as versioned JSON. Validate its format and preview the exact target count and classifications before saving it. The registry contains identifiers and review reasons, never provider credentials. Registry approval changes which records future manual refreshes may read; it does not start a payment, change a subscription, or alter CRM records. Disable a target with a reason to stop including new activity from it, or re-enable it with a reason. Disabling keeps the approved historical cash already saved in the report. Old-account coverage describes the approved targets and selected dates; **Approved scope verified** never means the entire old account was reconciled. Editing the approved registry makes saved old-account coverage provisional until a refresh or verified import checks the current registry. Location cash is also provisional when no snapshot is available or the selected dates are invalid. Keep target labels and reasons specific enough for another administrator to review. Add exact **Location IDs** and **Location binding evidence** when the source can be linked to a CRM Location. Use **Edit target evidence** to correct a saved mapping; this preserves the target’s enabled state. Multiple candidate IDs remain ambiguous, and clearing IDs removes that target’s mapping. Review the binding details in the Locations view before assigning cash to a Location. The Sources view also lists old-account invoice payment exceptions, including externally recorded invoice payments and invoices without a verified Stripe charge. Open the invoice evidence link to investigate. These records are excluded from Stripe gross and net cash until a real processor movement is established. ## Refresh a selected period Select a date range and choose **Refresh selected dates**. Dates use UTC, including both selected days. The source status shows which accounts were checked, the period covered and when the data was retrieved. Refreshes are manual. Larger historical reads from the newer account resolve invoice identities in pages to avoid a separate lookup for every payment. The older account remains limited to approved exact sources. If the selected source scope cannot be completely read, the last successful snapshot stays available with an error that names the cause, such as a read limit or a provider rejection. A missing connection is never reported as zero revenue. Narrow the period and retry if the read reaches its limit. Use the account and currency filters to inspect each source. Currencies remain separate. The report uses each cash movement's own date: a refund in October for a September sale reduces October collections, rather than rewriting September. ## Read the totals * **Gross collections** are actual captured payments. * **Refunds** are refund withdrawals. Failed refunds returned by the processor appear as adjustments. * **Disputes** show withdrawals separately from money reinstated after a win. * **Fees** include the fees on those movements and separate processor fee entries. * **Net cash** is the signed activity after fees, excluding bank payouts, internal transfers, and reserve or authorization holds. * **Payouts** transfer money already collected; they are not additional revenue. Pending processor funds have been collected but are not yet available for payout. A pending dispute is not automatically a final loss. A won dispute does not become a second sale. The original payment, refund and dispute movements retain their own processor identifiers so they cannot be counted twice. These are cash totals, not earned revenue or profit. An annual prepayment appears as cash collected when paid; its earned revenue depends on the service period. Taxes, non-Stripe receipts, reserves and other balance adjustments need their own accounting treatment. Match the report to processor balances and bank payouts before treating it as the complete financial close. ## Review Funding Machine classifications The older account also collected payments for other products, so its read boundary comes from the approved source registry. Within the report, review unclassified payments from the newer account and classify the charge as **FM owner**, **FM usage**, **Other**, or **Unclassified**, with a reason. A saved charge classification applies to its related refund and dispute movements. The review records the administrator and time; restoring the source classification reverses the override without erasing its audit history. Classification changes reporting only, not subscriptions, customer access or money movement. Use transaction filters to narrow the review, select up to 100 distinct charges, and apply a classification with a shared reason. Review the selected count before saving. A batch succeeds together; it does not partially apply. Individual reviews can still be reverted from their movement evidence. Unclassified new-account amounts remain in cash totals, because that account’s transactions are in the authorized Funding Machine source scope. Their owner/usage attribution still needs review; inclusion in cash does not mean CRM evidence has been reconciled. An all-category view is useful for new-account processor balance checks and must not be described as Funding Machine revenue. The old account remains limited to approved Funding Machine activity even when **All classifications** is selected. ## Compare Locations Open **Locations** to compare gross collections and net cash paid to Funding Machine for active and inactive CRM Locations. This view does not report the Operator’s own client revenue. CRM activity status is independent from subscription or payment activity; an invalid connection alone does not prove a Location is inactive. The date, account, and currency filters apply to Location cash totals. Transaction search, transaction classification, and CRM exception filters apply to the transaction view. New-account payments count even while their owner/usage category is awaiting review. Old-account payments remain limited to the approved Funding Machine scope. New-account payments can also use the exact Location ID in an owned CRM billing URL. Related refunds and disputes follow their charge. Payer-level evidence is used only when the available snapshot and saved bindings agree on one Location; conflicting evidence remains ambiguous and unknown IDs do not create Locations. Payments with missing or ambiguous Location evidence stay in an explicit unassigned pool. They are not distributed across Locations by similar names or amounts. Keep that pool visible when assessing whether every Location has been accounted for. Large metadata lists are bounded so the cash report remains available. If a list is cut short, coverage is marked **partial** and the report explains the limit. Incomplete billing mappings leave cash unassigned instead of inferring a Location from a weaker match. The saved historical ledger is retained. First-signup dates use recorded evidence where available. A fallback based on the earliest verified billing activity is labeled as an estimate and identifies its source. Exact charge-to-Location evidence also preserves older payment dates when the payer has no Stripe customer record. An unknown date remains unknown rather than becoming a claimed signup date. Only one report change can save at a time. If another change is still saving, wait for its result and retry the second action. ## Investigate CRM exceptions Use the exceptions view and open a transaction's details. Follow the Stripe and CRM evidence links to inspect the original record. Matching uses account and transaction identifiers; a similar name or amount does not create an automatic association. A missing CRM payment is different from a missing refund. If the original sale never existed in Operations, importing only the sale would overstate collections unless its refund is also accounted for. If the CRM already has the payment, compare the current cumulative refunded amount with Stripe. An unavailable CRM read remains unknown, not a confirmed missing payment. Do not issue another refund to correct reporting. This dashboard contains no payment, refund, cancellation or account-access actions. ## Import and export Use the downloadable snapshot template for the versioned JSON import format. Preview and validate the import before saving it. Source account, scope, dates, integer monetary amounts, unique transaction IDs and coverage are validated. Old-account entries must belong to an approved exact subscription or charge target; a snapshot import cannot expand that account’s approved read boundary. Imports are limited to 10 MB and 8,192 movements. Larger files upload directly to the application’s configured storage after an administrator validates the preview; CRM session credentials are never sent with the file. Reports load in verified pages and appear only after every page has arrived, so an interrupted load never presents partial cash as a complete total. A shorter date range may still be needed if the movement limit is exceeded. Only import trustworthy processor extracts; an import's claimed completeness is not independently proven by the dashboard. Export the filtered transaction view as CSV to preserve the processor IDs, amounts, classifications and reconciliation findings. Keep the account, date, currency and category filters with an exported report so its scope is clear. The native CRM transaction importer does not support refund backfills. Do not import gross historical sales merely to make its revenue widget agree. Use this reconciled ledger while any supported repair is verified. ## Connections and rollout Live reads use the existing server-side credentials for the two explicitly configured billing accounts and the scoped Operations CRM installation. Account identity is checked before ingesting transactions. Credentials are never entered into or returned by this dashboard. If a source is unavailable, an administrator must resolve that connection before the selected period can be complete. The new database tables and application code must be released together through the repository's normal deployment process. Preview fixtures contain synthetic data only. A local preview does not populate the production dashboard. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.