party-ledger-reconciliation – Other skill for AI agents

Party / Ledger Reconciliation

What it is: Customer and supplier balances proved against statements, differences found and adjustment entries passed.

Overview

Works out the smallest useful Party / Ledger Reconciliation setup for the business in front of it, then

builds it only when asked. The default output is a short recommendation, not a

spreadsheet. Artifacts - CSV, SQL DDL, JSON Schema, Notion mapping - are produced on

request, from one field list so they cannot drift apart.

Run it monthly, or more often for the high-volume and high-value parties. A balance that is

only checked at year end is a balance nobody can prove.

Layer: Layer 7: Reconcile. Fits: Growth stage. Table code: n/a.

When to Use This Skill

• customer balance confirmation
• supplier statement reconciliation
• debtor ledger check
• accounts confirmation

Also use it when the user says "customer and supplier balances proved against statements, differences found and adjustment entries passed", or describes the same process happening in a

spreadsheet, a document or someone inboxes.

Do not use it for: posting routine sales or purchase entries, tax filing, or legal advice.

This skill produces empty templates only - it never holds or processes real employee or

customer data.

How It Works

No separate shared execution contract is bundled; follow this file and current host/user instructions. The module-specific rules below define only domain fields, decisions, calculations, and safety constraints.

Step 1 - Identify intent

Read the request and pick the intent before asking anything.

• "set up" or "build" or "create" -> the user wants artifacts; go to Step 2.
• "our process is ..." or "it is in a sheet" -> the user wants to move an existing process; capture it, then Step 2.
• "is this right" or "review" or "audit" -> the user wants a check, not a build; answer from what they share.
• "how do I ..." -> advice question; answer directly and offer the build only if it helps.

Ask only if this is the highest-value missing fact; otherwise proceed without an opener:

> Q: How often do you check a customer's balance against their statement?

Step 2 - Ask only what is missing

Treat ambiguous replies as unanswered and ask which explicit option the user means. Record unknown values as Unknown; Unknown is not zero. A record must not be Done when a required check fails.

Skip anything the user already answered, in any earlier message. Ask the rest one at a

time, and stop as soon as the remaining answers would not change the output.

• Parties - How many customers and suppliers? / Which ones are high value? / Any on credit terms?
• Balances - Ledger balances maintained? / Statements received from parties? / Who prepares them?
• Confirmations - Do you send balance confirmations? / Who signs off? / How are disputes handled?
• Adjustments - Who can pass an adjustment entry? / What needs verification first?
• Outcome - What do you need? / A reconciliation record, a confirmation log or both?

Never invent an answer. If the user does not know, record it as unknown and carry on.

Step 3 - Hold the internal context

Hold the answers in this shape. It stays internal - it is not shown to the user unless

they ask, and it never carries a value the user did not give.

module: party-ledger-reconciliation
intent: null            # setup | advice | review | fix | build | convert | export
scale: null             # Starter | Growth | Scale, only if the answer changes it
areas:
  "Parties": null
  "Balances": null
  "Confirmations": null
  "Adjustments": null
  "Outcome": null
requested_outputs: []   # csv | sql | json | notion | xlsx - requested formats only
confirmed_facts: []     # only what the user actually said
open_questions: []      # the unanswered ones, in the order worth asking

Step 4 - Recommend the smallest workflow

Build an already requested artifact without asking again. For advice-only requests, give a short recommendation and offer the relevant artifact.

Recommended approach: One reconciliation record per party per period, holding the ledger balance, the statement balance, the difference, the reason for it and the adjustment entry that clears it.

Why this one: Most party disputes are proof problems, not arithmetic problems. Holding both balances and the reason on one record makes the difference explainable instead of arguable.

Workflow: Ledger balance agreed → Statement requested → Difference investigated → Confirmation sent → Adjustment passed

Step 5 - Build only on request

Once the user asks for it, derive the fields from the confirmed context and emit the

requested artifacts. For machine-readable text, keep prose outside the data; for files,

provide a usable link. Report material validation failures or limitations separately.

**A selected Notion output is rendered by notion-manual-import, so route the

Notion step there.** When the user selects Notion, hand that step to

@notion-manual-import: it holds the CSV, the property

mapping, the import steps and the verification checklist, and it renders the Field

Reference below instead of defining a table of its own. Do not restate the mapping

here and do not improvise the import steps. Manual CSV and mapping outputs need no

connection. For requested workspace changes, follow the shared contract: verify actual

tool access and the target before writing. A user saying "connected" is not tool evidence.

Never ask for a Notion password or token.

Reconciliation Number,Period Start,Period End,Party Type,Party Name,Party PAN/VAT,Ledger Balance,Statement Balance,Difference,Missing Invoices,Missing Receipts/Payments,Duplicate Entries,Credit/Debit Notes,Unadjusted Advances,Confirmation Sent,Confirmation Date,Confirmation Status,Difference Reason,Adjustment Required,Adjustment Entry,Adjustment Date,Adjusted By,Reconciliation Frequency,Reviewed By,Status,Notes,Reconciliation ID
REC-2026-0044,2026-08-01,2026-08-31,Customer/Debtor,Greyson Foods,SYNTHETIC-TAX-ID,486200.00,471200.00,15000.00,1,2,3,4500.00,15000.00,Yes,2026-09-03,Partially Confirmed,Advance held in our books but not credited by the party,Yes,ADJ-2026-0118,2026-09-05,Sneha Iyer,Monthly,Vikram Singh,In progress,"2 missing receipts, 3 duplicate entries and a 4500.00 credit note cleared on both sides; difference matches the unadjusted advance, adjustment raised and pending review.",REC-ID-0044

CREATE TABLE party_ledger_reconciliation (
  reconciliation_number VARCHAR(255),
  period_start DATE NOT NULL,
  period_end DATE NOT NULL,
  party_type VARCHAR(100) NOT NULL,
  party_name VARCHAR(255),
  party_pan_vat VARCHAR(255),
  ledger_balance NUMERIC(14,2),
  statement_balance NUMERIC(14,2),
  difference NUMERIC(14,2),
  missing_invoices NUMERIC,
  missing_receipts_payments NUMERIC,
  duplicate_entries NUMERIC,
  credit_debit_notes NUMERIC(14,2),
  unadjusted_advances NUMERIC(14,2),
  confirmation_sent VARCHAR(100),
  confirmation_date DATE,
  confirmation_status VARCHAR(100) NOT NULL,
  difference_reason VARCHAR(255),
  adjustment_required VARCHAR(100) NOT NULL,
  adjustment_entry VARCHAR(255),
  adjustment_date DATE,
  adjusted_by VARCHAR(255),
  reconciliation_frequency VARCHAR(100),
  reviewed_by VARCHAR(255),
  status VARCHAR(100) NOT NULL,
  notes TEXT,
  reconciliation_id VARCHAR(255) PRIMARY KEY,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX idx_party_ledger_reconciliation_status ON party_ledger_reconciliation (status);

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Party / Ledger Reconciliation",
  "type": "object",
  "additionalProperties": false,
  "properties": {
      "Reconciliation Number": { "type": "string" },
      "Period Start": { "type": "string", "format": "date" },
      "Period End": { "type": "string", "format": "date" },
      "Party Type": { "type": "string" },
      "Party Name": { "type": "string" },
      "Party PAN/VAT": { "type": "string" },
      "Ledger Balance": { "type": ["number", "null"] },
      "Statement Balance": { "type": ["number", "null"] },
      "Difference": { "type": ["number", "null"] },
      "Missing Invoices": { "type": "number" },
      "Missing Receipts/Payments": { "type": "number" },
      "Duplicate Entries": { "type": "number" },
      "Credit/Debit Notes": { "type": "number" },
      "Unadjusted Advances": { "type": "number" },
      "Confirmation Sent": { "type": "string" },
      "Confirmation Date": { "type": "string", "format": "date" },
      "Confirmation Status": { "type": "string" },
      "Difference Reason": { "type": "string" },
      "Adjustment Required": { "type": "string" },
      "Adjustment Entry": { "type": "string" },
      "Adjustment Date": { "type": "string", "format": "date" },
      "Adjusted By": { "type": "string" },
      "Reconciliation Frequency": { "type": "string" },
      "Reviewed By": { "type

… (full content is in the download package)