Finance and AI,
defined plainly.

Money a business owes its suppliers for bills that have been received but not yet paid. AP is the mirror image of accounts receivable: AP is money going out, AR is money coming in. The AP balance at any moment is the sum of unpaid bills, less any vendor credits applied against them.

AP questions are answerable because they are filters and sums over bill, bill payment, vendor, vendor credit, and purchase order records, all of which Kipper reads. "Which bills from Northwind are still unpaid?" or "what did we pay this supplier last month?" resolve directly. See what Kipper reads from each system.

Money customers owe a business for invoices that have been issued but not yet paid. AR is usually the first thing anyone outside finance wants to know about, because it answers the question behind most customer conversations: has this account paid us, and if not, how much and how late?

Outstanding balances by customer, invoices overdue past a given date, and payments received in a period are all direct lookups over invoice, payment, customer, and credit note records. A sales rep can ask before a renewal call; a support agent can check before escalating an account.

Unpaid invoices grouped by how long they have been outstanding: conventionally current, 1–30 days, 31–60 days, 61–90 days, and 90+ days. An aging list is how a business sees which receivables are merely recent and which are genuinely at risk.

Because aging is a filter and a sum over invoice records rather than a ledger report, Kipper produces it directly: "show me AR aged over 60 days" returns the actual invoices and the total. This is one of the most common requests finance teams field from the rest of the company, and one of the easiest to hand back to the people asking.

A supplier's request for payment, recorded in the finance system. A bill is the accounts-payable counterpart of an invoice: an invoice is money owed to you, a bill is money owed by you. In Xero a supplier's bill sits against a contact; in QuickBooks and NetSuite it sits against a vendor.

Bills, bill payments, and vendor credits are all readable, so "has this bill been paid?" and "what do we still owe this supplier?" are answerable. A buyer or operations lead can check before approving the next purchase without a finance-system seat.

The structured list of accounts (assets, liabilities, income, expenses) that every transaction in a business is coded against. The chart of accounts is the skeleton of the general ledger, and it is what makes account-level reporting possible.

Kipper does not query the chart of accounts or account-level balances. It reads transaction records (invoices, bills, payments, customers, vendors, inventory), so account-coded questions stay in the finance system. For breaking answers down by part of the business, the field to use is Class or its equivalent, not the account code.

The grouping dimension a finance system uses to split transactions across parts of a business: a team, location, project, product line, or cost center. Every major system has one, and each calls it something different: Class in QuickBooks Online, Tracking Category in Xero, and Class or Department in NetSuite.

Where a finance team already populates this field, Kipper can group answers by its values: invoices by location, bills by project. Where they have not, it cannot: Kipper groups by fields that exist in the data and will not infer a breakdown by industry or customer sector, because those are not real fields in any of these systems.

A record that reduces what a customer owes, or what a business owes a supplier, without cash changing hands, issued when goods are returned, an overbilling is corrected, or a discount is applied after invoicing. It is called a credit note in Xero and a credit memo in QuickBooks and NetSuite; the supplier-side equivalent is a vendor credit or supplier credit.

Kipper tracks the portion of an invoice or bill settled by a credit note separately from cash payments, so an invoice counts as fully settled only when payments plus credits cover its full amount. That distinction matters when a balance looks wrong: the money may have been credited rather than collected.

The average number of days a business takes to collect payment after a sale, calculated over a period from receivables and revenue. DSO is a headline efficiency metric for a finance team, and a rising DSO is an early warning about collections.

DSO is a calculated ratio, and Kipper does not compute financial ratios. It answers questions from records rather than producing reporting metrics. What it can give you is the underlying detail the calculation rests on: the invoices, the payments against them, and the aging.

The master record of every financial transaction a business has posted, organized by account. The general ledger is what a finance team closes, reconciles, and reports from, and it is the source of the financial statements. Everything else in accounting eventually lands here.

Kipper does not read the general ledger. It reads transaction-level records, which means GL-level questions are outside what it answers: profit and loss, trial balance, revenue recognition, and account reconciliation all stay in the finance system. This is a deliberate architectural boundary, not a missing feature. The records Kipper does read are the ones that answer operational questions.

A request for payment issued to a customer, listing what was sold, at what price, and when payment is due. The invoice is the single most-referenced record in any finance system, because it is the point where a commercial agreement becomes a receivable.

Invoices and their payments are the records Kipper is asked about most: outstanding balance, payment status, overdue lists, line-item detail, and date-range comparisons such as invoiced this month versus last. See the questions people actually ask on QuickBooks, Xero, and NetSuite data.

A direct debit-and-credit posting made to the general ledger, usually by an accountant, to record something that does not arise naturally from an invoice, bill, or payment: an accrual, a depreciation charge, a reclassification, or a period-end correction.

Kipper does not read journal entries, so anything that depends on them cannot be answered: accruals, adjustments, and period-end corrections are invisible to it. A figure adjusted by journal entry will therefore differ from the transaction-level total Kipper reports, and that is expected.

The recurring process a finance team runs to finalize a period: posting remaining journal entries, completing reconciliations, reviewing accounts, and locking the books so reporting can be produced from a fixed set of numbers.

The close is a workflow performed inside the finance system by the people who own the ledger, not a question with an answer. Kipper is not an accounting or bookkeeping workflow tool and does not participate in it. What it does is absorb the lookup requests that would otherwise interrupt the team during close.

Money received from a customer beyond what they owed, or paid to a supplier beyond what was billed. An overpayment sits as a credit until it is applied to a later invoice or bill, or refunded.

Overpayments are a distinct record type in Xero, and Kipper reads them on Xero connections only. On a Xero connection Kipper tracks how much of an overpayment is still unapplied, how much has been used to settle later invoices or bills, and how much has been refunded. It is often where an unexplained customer balance turns out to have come from.

Money received from a customer, or paid to a supplier, before an invoice or bill exists: a deposit or retainer against future work. Like an overpayment, it is a credit waiting to be applied.

On Xero connections, Kipper tracks the unapplied, applied, and refunded portions separately, so "how much of this deposit is still unused?" is answerable. Prepayments are not available on QuickBooks or NetSuite connections today.

A document issued to a supplier committing to buy goods or services at an agreed price, raised before the supplier bills for them. The PO is the control point in procurement: it is what a received bill gets matched against.

Purchase orders are readable, so questions about what has been ordered but not yet billed are answerable. PO coverage is widest on NetSuite, which also exposes sales orders, quotes, quantity on hand, and bills of materials that the accounting platforms do not carry.

The process of matching the records in an accounting system against an independent source, most often a bank statement, to confirm the two agree, and investigating anything that does not. Bank reconciliation is a core part of bookkeeping and a prerequisite for trustworthy reporting.

Reconciliation is outside what Kipper does, for two reasons. It is a workflow rather than a lookup, and it depends on bank-transaction data that Kipper does not read in any connected system. Anything derived from bank data (cash position, cash balance, runway, burn rate) is out of scope for the same reason.

Application Programming Interface: the documented interface a software product exposes so other software can read or write its data. Every connection Kipper makes to NetSuite, QuickBooks, or Xero runs through that system's API, which is why nobody has to export a spreadsheet for a question to be answered.

An API defines the ceiling on what any integration can reach: if a system's API does not expose a record, no tool in front of it can read that record, however it is marketed. That is why coverage differs by system rather than being uniform. For how an API differs from the protocol AI assistants use, see MCP versus API.

Enterprise Resource Planning: a single system that runs finance alongside inventory, procurement, order management, manufacturing, and other operations. NetSuite is an ERP; QuickBooks and Xero are accounting platforms with a deliberately narrower scope.

The practical difference is record coverage. An ERP holds operational records (sales orders, quotes, quantity on hand, bills of materials) that accounting platforms do not, which is why so many non-finance questions have an ERP answer. ERP seats are also expensive and the interface assumes training, which is the usual reason most of a company never gets a login. Compare a Kipper seat against an ERP seat.

Combining the results of several legal entities, subsidiaries, or accounting files into one set of figures, with intercompany transactions eliminated so nothing is double-counted. Businesses operating across markets or brands usually run several entities and consolidate for reporting.

Consolidated and intercompany figures are reporting-level output built on the general ledger, so Kipper does not produce them. It answers questions against the records in a connected system. Connecting multiple entities is a separate matter from consolidating them. See multi-entity Xero connections.

An integration permitted to read records but never to create, edit, or delete them. Read-only is the security posture most finance teams require before letting any tool near the books, because it removes the possibility of a downstream system corrupting the ledger.

Kipper is read-only at the architecture level rather than by configuration, so there is no write path to disable or misconfigure. What each person can read is scoped separately by a workspace admin, and questions are logged. See what read-only access looks like in practice.

When an AI system produces an answer that reads as plausible but is not grounded in real data. In most applications a hallucination is an annoyance. In finance it is the central risk, because a confident, well-formatted, invented number is considerably worse than no answer at all. It gets quoted to a customer before anyone checks it.

Kipper's defense is architectural rather than statistical. It does not predict what a number probably is: it translates the question into a SQL query, runs that query against synced records, and returns what came back. The language model never produces the figure. When the data cannot answer a question, Kipper says so instead of estimating.

An AI model trained on large volumes of text that interprets a request in natural language and generates a response. LLMs are what make it possible to ask a database a question in plain English instead of writing code.

In Kipper the model's job is strictly translation: turning a plain-English question into a query, not arithmetic and not figures. The numbers come from finance records. Inference runs through Amazon Bedrock; the specific models are an implementation detail and change over time.

An open standard that lets AI assistants connect to external data sources and tools, so an assistant can look something up rather than answering from training data alone. MCP is how a general-purpose assistant gains access to a specific business system.

Kipper runs an MCP server, which is how assistants such as ChatGPT, Gemini, and Claude can reach finance data under the same read-only, permissioned, logged access as every other interface. Setup by system: NetSuite, QuickBooks, and Xero.

An AI technique that retrieves relevant passages from a document store and feeds them to a language model, which then composes an answer from them. RAG is well suited to document search (policies, contracts, knowledge bases) where the answer genuinely lives in prose.

Kipper does not use RAG. Retrieved passages give a model text about your numbers rather than the numbers themselves, which is precisely how a hallucinated figure gets produced. Structured finance data should be queried, not retrieved and paraphrased.

A structured database query: the standard language for asking a database an exact question and getting an exact set of rows back. A SQL query either returns the matching records or it does not; there is no interpretation step in the middle.

Kipper translates a plain-English question into SQL and runs it against synced finance data. There is no RAG or document search involved, which is what keeps an answer tied to actual records rather than a model's estimate. On NetSuite the equivalent query surface is SuiteQL. See SuiteQL for NetSuite data.