Party / Ledger Reconciliation

Party Ledger Reconciliation defines one reconciliation record per party and period. It holds the ledger balance, statement balance, difference, explanation and adjustment entry that resolves it. The proposed sequence agrees the ledger balance, requests the statement, investigates differences, sends a confirmation and passes an adjustment. These are defined people and accounting steps, not actions performed by the template. Monthly reconciliation is recommended, with greater frequency for high-volume or high-value parties; high-value parties should still be checked monthly when others can wait a quarter.

The default deliverable is a short recommendation. An explicit setup, build or conversion request produces artifacts after essential missing facts are resolved. Advice receives a direct answer, while a review works from the material provided. This keeps the size of the proposed setup tied to the requested outcome.

Use it for customer balance confirmation, supplier statement reconciliation, debtor-ledger checks and accounts confirmation. It does not post routine sales or purchase entries, compute balances, contact parties, send confirmations or chase statements. It does not provide tax, audit or legal advice.

This is an empty-template workflow, not processing of real employee or customer records. Automation, reminders and synchronization require the separate integration layer. Sensitive decisions and adjustments require qualified human review before anything is acted on.

Intake establishes customer and supplier counts, credit terms and high-value parties, who maintains balances and prepares statements, confirmation sign-off, dispute handling and adjustment authority. It distinguishes a reconciliation record from a confirmation log, or a need for both. Questions are asked one at a time, excluding anything already answered in earlier messages. Unknown facts stay unknown. Intent, confirmed facts, open questions and requested formats remain internal unless the user asks to inspect them; no missing answer is invented.

The field model includes Reconciliation Number (text); Period Start (date); Period End (date); Party Type (select); Party Name (text); Party PAN/VAT (text); Ledger Balance (currency); Statement Balance (currency); Difference (currency); Missing Invoices (number); Missing Receipts/Payments (number); Duplicate Entries (number); Credit/Debit Notes (currency); Unadjusted Advances (currency); Confirmation Sent (select); Confirmation Date (date); Confirmation Status (select); Difference Reason (text); Adjustment Required (select); Adjustment Entry (text); Adjustment Date (date); Adjusted By (text); Reconciliation Frequency (select); Reviewed By (text); Status (select); Notes (long_text); Reconciliation ID (id).

Party Type starts with Customer/Debtor, Supplier/Creditor, Employee, Bank, Other. Confirmation Sent starts with Yes, No, Not Required. Confirmation Status starts with Not Sent, Sent, Confirmed, Partially Confirmed, Disputed, No Response. Adjustment Required starts with Yes, No. Reconciliation Frequency starts with Monthly, Quarterly, Half-Yearly, Annual. Status starts with Not started, In progress, Blocked, Done, Cancelled.

Ambiguous answers require clarification. Unknown is not zero, and a failed required check prevents Done. An adjustment must wait until the difference has an explanation. Even a nil difference requires a named reviewer and recorded reason; a write-off requires its own evidence. A reconciled figure is not confirmation that the party agrees. Related accounting modules cover sales invoices, receipts, aging priorities and monthly ledger totals; accounting-audit-system-builder routes the wider workflow. Party tax identifiers remain masked until needed.

Requested CSV, SQL DDL, JSON Schema and Notion mappings derive from one field list. Display names remain identical across CSV and JSON, and normalized SQL identifiers are documented. Relation fields keep their relational meaning, dates remain dates and money remains currency. Machine-readable data is separated from explanation, with validation failures and limitations reported separately.

One supplied SQL example is:

CREATE INDEX idx_party_ledger_reconciliation_status ON party_ledger_reconciliation (status);

Because CSV has no column types, numeric, date and currency formatting is identified after the data. A CSV is not an .xlsx workbook; the latter is generated only when requested. Example rows require an explicit request and must be clearly synthetic. Sensitive identifiers are not unnecessarily repeated in a review, and generated templates remain empty.

Notion output goes to notion-manual-import for the CSV, property mapping, import steps and verification checklist. Manual mappings require no connection. Requested workspace changes require verified tool access, the actual target and authorization; a claimed connection is insufficient evidence. Notion relation columns resolve only after both databases have been imported. Select options are an initial vocabulary that can be renamed to match the business. Personal identifiers and sensitive financial details stay out of generated templates.