expense-accounting – Documents & Office skill for AI agents

Expense Accounting

What it is: One row per bill or valid supporting document, carrying the nature of the expense, the document behind it, the applicable tax information and the ledger account together.

Overview

Works out the smallest useful Expense Accounting 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.

Three guardrails shape the whole table.

Tax is recorded, never assumed. Being VAT-registered does not tell you the rate, whether

the expense is taxable, whether input tax is recoverable, whether the amount is

tax-inclusive, or whether a reverse charge or another treatment applies. TDS is not part of

an expense entry at all unless the business actually deducts it. Every tax field in the

minimum schema is optional until a rate *and* a treatment have been supplied by the user.

An expense entry is not a payment. Payment mode, payment date, payment reference, net

payable, TDS and department are payment-stage facts. They do not appear in an expense-only

setup. If the user asks for payment tracking, that is a deliberate scope change and the

fields are added then, not by default.

The document must be the real document. Where no formal invoice exists, the adequacy of an internal supporting document depends on the jurisdiction, transaction and reviewer decision; farmer purchases, wages or rent are examples to investigate, not blanket exemptions. The absence of an invoice does not automatically justify raising a

purchase "Kharche/Kharpai". Document Type, Internal Support Justified and

Justification exist to hold that decision, and a reviewer holds it, not this skill. No

label in the Document Type list makes any document legally sufficient.

Layer: Layer 5: Expense & Payroll. Fits: Starter stage. Table code: n/a.

When to Use This Skill

• expense register
• petty expense sheet
• expense book with tax
• bill and voucher log
• expenses booked to the right account

Also use it when the user describes the same process happening in a spreadsheet, on paper,

or in someone's inbox.

Do not use it for: payroll calculation, tax filing, tax-return preparation, legal advice,

deciding whether a transaction is legally deductible, deciding which tax rate applies,

deciding whether a supporting document is legally sufficient, or processing real employee,

customer, supplier, PAN, VAT or banking data. This skill produces templates only.

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" / "build" / "create" -> a new structure; go to Step 2.
• "our expenses are in a sheet" / "we currently record ..." -> capture the existing

process first, then Step 2.

• "is this right" / "review this" / "audit this" -> a check, not a build; answer from what

they share and do not rebuild.

• "how do I ..." -> advice; answer directly and offer a build only if it helps.

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.

One message, one question, no batching. Skip anything the user already answered, in any

earlier message. Ask only questions whose answer would change the recommended structure or

the requested artifact. Stop as soon as the remaining unknowns would not change the output.

Record Unknown and move on when the user does not know, and never ask the same unknown

twice.

The opening question targets the highest-value missing fact. Do not ask for the largest

expense category as a warm-up because it does not change the table structure.

For a new setup the usual first question is:

> Q: What do you want to record: expense entries only, payments too, or both?

Then, only as needed:

• Existing process - Are you starting from scratch, or replacing an existing sheet or

book?

• Categories - What expense categories do you actually use? If the user does not

know, keep Category configurable. Do not impose a standard category list as though it

were confirmed.

• Documents - Do you normally receive a bill or invoice for each expense? If not,

what do you keep when there is no formal bill? Record the actual document type.

• Tax - Which tax information do you need on each expense? If VAT/GST: do you need the

rate and the amount recorded separately? If TDS/withholding is not used, TDS fields are

absent from the schema rather than optional-but-present.

• Accounting - Do you assign each expense to a ledger account? Who decides the account?
• Approval - Does someone approve or review each entry? Who performs it? Add only the

approval fields the process needs - Approved By alone may be enough.

• Payment - Ask payment questions only if payment tracking is in scope.
• Outcome - An expense register, a payment file, or both? Which artifacts do you want?

Ambiguous answers are not answers. yes, no, maybe, same, okay and fine do

not resolve a multiple-choice question. Re-ask as an explicit choice rather than guessing.

Partial answers keep only the answered part. If a question has two parts and the user

answers one, record that one and leave the other Unknown.

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

Never turn Unknown into 0, and never treat a blank as a confirmed zero. A rate the user

has not supplied stays blank until they supply it.

Step 3 - Hold the internal context

Keep 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: expense-accounting
intent: null            # set in Step 1: set up | fix | review | report | import
scale: null             # Starter | Growth | Scale, only if the answer changes it
areas:
  # Scope is the first area: expense entries only | payments too | both
  "Scope": null
  "Documents": null
  "Tax": null
  "Accounting": null
  "Approvals": null
  # Tracked with the same discipline, recorded only when the answer changes the build:
  #   "Categories"       - the user's own category list, or configurable
  #   "Existing Process" - from scratch, or replacing an existing sheet or book
  #   "Outcome"          - the artifacts actually requested
requested_outputs: []   # csv | sql | json | notion | xlsx - requested formats only
confirmed_facts: []     # only what the user actually said
unknowns: []            # asked and not answered
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 expense row per bill or valid supporting document, carrying the expense nature, document information, applicable tax information, ledger account and approval/review status on the same row.

Why this one: Keeping the document and tax treatment linked makes reconciliation easier. Separate linked registers can also be auditable; auditability depends on controls and evidence.

Workflow: Nature identified → Supporting document recorded → Payee verified → Tax treatment recorded → Ledger account assigned → Approved/reviewed → Entry verified

Payment and TDS steps are added only when the confirmed process requires them.

If no artifact was requested, offer the relevant format. Otherwise continue the build.

Step 5 - Build only on request

Once the user asks, derive the fields from the confirmed context and emit **only the

artifacts that were requested**. No preamble, no summary, no closing line, no unrequested

artifact.

**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.

The shapes below show the documented default for an expense-only setup. Drop any field the

confirmed process does not justify; add a field only when a confirmed requirement

… (full content is in the download package)