sales-accounting – Marketing & SEO skill for AI agents

Sales Accounting

What it is: Sales invoices, the receivables they create, and the documents that support them.

Overview

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

Scope of one row. This is a single-table skill and one row is one invoice carrying

one line item. It is deliberately not a multi-line billing engine. An invoice with

several items requires an invoice header with a separate line table. Do not repeat invoice totals, payments or balances per item: summing them would double-count receivables.

Decide that in Step 2, do not assume it.

Everything is conditional. Not every sale is on credit, not every invoice has an order

or a challan, not every sale attracts VAT, and not every customer deducts TDS. Those fields

exist to record what was confirmed; they are left unset when the answer is "not applicable"

or "not known". Never fill them with a default to make the row look complete.

Layer: Layer 3: Record. Fits: Starter stage. Table code: n/a.

When to Use This Skill

• sales accounting
• sales invoice register
• customer billing and receivable tracker
• sales vat register log

Also use it when the user describes invoicing, billing or tracking who has paid, or the same

process happening in a spreadsheet, a document or someone's inbox.

Do not use it for: customer collections, tax filing, or legal advice. This skill produces

empty templates only - it never holds or processes real customer or financial 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.

Then read everything the user has already said and work out which single missing answer

would actually change the recommendation. If the request already contains enough to

recommend, do not ask anything yet - go to Step 4. If the user is describing a problem

rather than requesting a build, answer it first; a question is not owed.

Never open with a fixed question such as "How are sales invoices raised today?" when the

request has already answered it.

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.

• Volume - How many invoices a month? / Roughly how many lines per invoice?
• Documents - Is there a sales order every time, or only for some customers? / Is a delivery challan used at all?
• Taxes and credit - Is VAT charged, and at what rate? / Do any customers deduct TDS, and at what rate? / How many sales are on credit? / Standard credit period? / Who follows up?
• Current process - Tracked now? / Software or sheet? / What gets missed?
• Outcome - What do you need? / A sales register, an aging view 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: sales-accounting
intent: null            # setup | advice | review | fix | build | convert | export
scale: null             # Starter | Growth | Scale, only if the answer changes it
areas:
  "Volume": null
  "Documents": null
  "Taxes and credit": null
  "Current process": 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. Use

conditional language and name what is conditional.

Recommended approach: One invoice register, one row per invoice with a single line item.

Link the sales order, delivery challan and source document only where the business actually

raises them. Record VAT and TDS rates only where they were confirmed. For credit sales, add

the credit terms, due date, amount received, balance, a payment status and an aging status;

leave those unset for cash sales.

Why this one: A sales register that stops at the invoice total loses the receivable.

Splitting payment state from aging state is what turns billing into a collections list -

"paid" and "overdue" are different questions and one field cannot answer both.

Workflow: Documents prepared (where used) → Invoice issued → VAT register updated (where VAT applies) → Recorded → Receivable confirmed against the debtor ledger

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.

The SQL below is written in PostgreSQL-flavoured DDL. SERIAL PRIMARY KEY and

TIMESTAMP DEFAULT NOW() are PostgreSQL-specific; on another engine use that engine's

identity column and default-timestamp syntax. created_at is initialized by the database; updated_at needs an application update or a trigger (DEFAULT alone does not maintain it). Both are technical metadata and are not business fields - leave them out of the CSV, JSON Schema and

Notion mapping.

Sales Number,Customer,Customer PAN/VAT,Sales Order,Delivery Challan,Invoice Number,Invoice Date,Item Description,Quantity,UOM,Rate,Gross Amount,Discount,Taxable Value,VAT Rate %,VAT Amount,TDS Rate %,TDS Amount,Invoice Total,Net Receivable,Credit Terms (Days),Due Date,Payment Status,Aging Status,Amount Received,Balance,Ledger Account,Source Document,VAT Register Updated,Entry Verified,Prepared By,Notes,Sales ID
SAL-2026-0033,Example Customer Ltd,ZZZZZ0000Z,SO-2026-0094,DC-2026-0911,INV-2026-0733,2026-08-16,Corrugated carton packs printed,800,Nos,142.50,114000.00,2280.00,111720.00,18,20109.60,2,2234.40,131829.60,129595.20,30,2026-09-15,Part Paid,Overdue,50000.00,79595.20,Sales - Cartons,DOC-2026-0455,Done,In progress,Example Preparer,Credit sale net 30; order raised for this customer only.,

-- PostgreSQL-flavoured DDL. See the note above for other engines.
CREATE TABLE sales_accounting (
  sales_number VARCHAR(255),
  customer VARCHAR(255),
  customer_pan_vat VARCHAR(255),
  sales_order VARCHAR(255),  -- relation -> sales order database
  delivery_challan VARCHAR(255),  -- relation -> delivery challan database
  invoice_number VARCHAR(255),
  invoice_date DATE NOT NULL,
  item_description VARCHAR(255),
  quantity NUMERIC NOT NULL,
  uom VARCHAR(100) NOT NULL,
  rate NUMERIC(14,2) NOT NULL,
  gross_amount NUMERIC(14,2) NOT NULL,
  discount NUMERIC(14,2) NOT NULL,
  taxable_value NUMERIC(14,2) NOT NULL,
  vat_rate_pct NUMERIC,
  vat_amount NUMERIC(14,2),
  tds_rate_pct NUMERIC,
  tds_amount NUMERIC(14,2),
  invoice_total NUMERIC(14,2) NOT NULL,
  net_receivable NUMERIC(14,2) NOT NULL,
  credit_terms_days NUMERIC,
  due_date DATE,
  payment_status VARCHAR(100) NOT NULL,
  aging_status VARCHAR(100),
  amount_received NUMERIC(14,2) NOT NULL,
  balance NUMERIC(14,2) NOT NULL,
  ledger_account VARCHAR(255),
  source_document VARCHAR(255),  -- relation 

… (full content is in the download package)