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

Follow the shared execution contract. 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.

…