accounting-software-selection – Data & Science skill for AI agents

Accounting Software Selection

What it is: The evidence behind a software purchase, recorded so the decision is arguable - and the decision itself still belongs to the business.

Overview

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

For a Nepal trading, manufacturing or services business, this is the record that makes the

purchase arguable: requirements ranked, a candidate shortlist, the same demo tests run

against every candidate, the evidence behind every score, cost split so first-year and

three-year totals can be compared, and the evaluation status, selection decision,

rejection reason and deal-breaker flag kept as four separate fields instead of one

opinion. It is an evaluation and decision-support tool, not a bookkeeping, tax-filing,

legal or procurement system.

Four guardrails shape every row.

Nothing is invented, and nothing is asserted without a source. Never supply a vendor

capability, a price, a compliance status, a demo result or a stakeholder score that the

user or a named source did not give. What nobody has verified is Untested for a

capability and an empty cost cell with Unknown in Notes for a price. A capability

nobody has looked at is Untested; it is not 1 Missing, and a blank is never filled

with a plausible number so the row looks finished.

This skill never selects. It may summarise the evidence, name the requirements a

candidate fails, and state that a Must-have is failed. It must not declare a package the

best option, announce a winner, state a compliance conclusion or record an approval. The

business fills Selection Decision itself.

Fact and opinion stay apart. The thirty capability fields carry what the vendor

documented or demonstrated. The three Rating fields carry the named evaluator's own

judgement. A brochure claim is never copied into a Rating, and an evaluator's impression

is never written into a capability field. An average across evaluators is not objective

truth and a score never becomes a recommendation.

Nepal tax and statutory claims need cited, current evidence. VAT, PAN, TDS, IRD

reporting, e-billing, CBMS, the Nepal fiscal year and BS/AD dates, payroll and SSF are

Untested until the business holds current evidence from the vendor or from the

authority. No compliance status is claimed from a brochure or a sales page, and absence

of evidence is not evidence of absence in either direction.

Layer: Layer 1: Foundation. Fits: Growth stage. Table code: n/a.

When to Use This Skill

• accounting software selection
• accounting and erp software comparison
• vendor demo evaluation sheet
• accounting package quotation tracker
• three year software cost comparison

Also use it when the user describes a scored evaluation of shortlisted accounting

packages before one is chosen, or the same process happening in a spreadsheet, a document

or someone inboxes.

Do not use it for: day-to-day bookkeeping once a package is live, tax filing, vendor

contracting or legal advice. This distribution produces templates and illustrative examples. It can review user-supplied evaluation summaries within the requested scope, but must not request unnecessary personal or confidential business records.

How It Works

Use the authorization and evidence rules in this file; no separate shared contract is bundled. 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.
• "compare" or "which one should we pick" -> the user wants an evaluation; capture the shortlist, then Step 2.
• "our process is ..." or "it is in a sheet" -> the user wants to move an existing evaluation; 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.
• "report" or "how do I ..." -> advice question; answer directly and offer the build only if it helps.

Then read everything the user has already said and find the single missing answer that

would change the evaluation most. If the request already contains enough to recommend,

do not ask yet - go to Step 4. If the user is describing a problem rather than requesting

an evaluation, answer it first; a question is not owed.

One message, one short question, no batching. Open with:

> Q: Which accounting or ERP packages are currently on your shortlist?

Never open with that when the request has already named the packages, and never open

with a question that does not change the output - "what is your biggest expense category

this month" tells you nothing about which package fits. If there is no shortlist, do not

force one: collect the business requirements first and build the candidate shortlist from

them in Step 4.

Do not clarify an optional identifier, label or reference before a fact that changes the

evaluation. Evaluation ID, vendor name and other optional record labels may remain

Unknown; ask about the shortlist first, or the business requirements when there is no

shortlist.

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, in the order below, because it runs from the answer that changes the comparison

most to the answer that changes it least. Stop as soon as the remaining answers would not

change the shortlist, a score or the build.

1. Shortlist - which packages, or that there is none and one has to be built from the requirements.

2. What the business does - trading, manufacturing, services, or a mix. This decides which of the 35 categories are worth scoring at all.

3. Scale - people, transactions a month, companies, branches, warehouses. Only ask if the answer would change the shortlist.

4. Requirements and their priority - ask for the list, then ask for each one to be ranked Must-have, Should-have, Nice-to-have or Not required. The deal-breaker rule needs that ranking before anything is scored.

5. Nepal requirements - VAT, PAN, TDS, IRD reporting, e-billing or CBMS, Nepal fiscal year and BS/AD dates, payroll, SSF. Do not assume a package supports any of them.

6. Platform - cloud or on-premise, permissions, approvals, maker-checker, backup, security, API, integrations, data export, migration, customization, local support, training.

7. Money - which currency, and whether a written quotation is in hand. Take a price only from a quotation.

8. Outcome - CSV, SQL DDL, JSON Schema, Notion mapping, a go-live checklist, or just the evaluation. Build nothing that was not asked for.

An answer that does not choose is not an answer. yes, maybe, same, okay and fine

to a multiple-choice question are rejected, and the choice is re-asked explicitly:

> Q: For the accounting scope, which do you mean: **general ledger and bank

> reconciliation only, or general ledger, receivables, payables and fixed assets**?

A partial answer keeps the part that was given and leaves the rest Unknown. Never fill

the gap.

Never invent an answer. Record it as Unknown and carry on, and never re-ask the same

unknown. Unknown is not zero, and Unknown is not a low score: a price nobody quoted

leaves the cost cell empty, and a capability nobody checked is Untested, never

1 Missing and never 0.

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: accounting-software-selection
intent: null            # set in Step 1, one of: set up, compare, review, report, import
scale: null             # Starter | Growth | Scale, only if the answer changes it
areas:
  "Shortlist": null
  "Business activities": null
  "Requirements priority": null
  "Nepal requirements": null
  "Platform and money": null
requirement_priority: null   # each need as Must-have | Should-have | Nice-to-have | Not required
candidates: []          # shortlist, each with its own row and its own evidence
unverified: []          # every capability still Untested and every cost still Unknown
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

unverified is the list that must be visible before a

… (full content is in the download package)