1.1

What an AIS actually does

An accounting information system is the organized combination of people, procedures, data, software, infrastructure, and controls that captures economic activity and turns it into information. The word accounting can make the definition sound narrower than it is. An AIS does not begin when a journal entry is posted. It begins when a customer places an order, an employee records time, a receiver accepts goods, or a manager approves a price change.

The system must preserve meaning as the event moves through the organization. A sales order means that a customer requested goods. A shipping record means that goods left the company. An invoice means that the company billed the customer. A cash receipt means that value was collected. Those records are related, but they are not interchangeable. Good AIS design keeps the distinctions visible while connecting the records into a coherent history.

For accountants, the central question is not simply whether data were stored. It is whether the system produced information that is reliable enough for a particular decision. The same system supports operations, management reporting, financial reporting, compliance, tax, and audit. Each user may need a different view, but all views should be reconcilable to the underlying events.

1.2

From data to information to a decision

Data are recorded representations of facts: an invoice number, quantity, timestamp, account code, or approval status. Information is data organized and interpreted for a purpose. A list of 8,000 open invoices is data. An aging report that identifies customers likely to miss payment terms is information because it changes what the credit manager can see and do.

Information quality is therefore contextual. Accuracy matters, but an accurate report can still be incomplete, late, difficult to understand, or irrelevant. A controller preparing the close may need a complete population and a documented reconciliation. A sales representative speaking with one customer may need a current balance immediately. The system should serve both decisions without silently changing definitions.

Accountants add value by asking disciplined questions: What business decision is being made? Which events belong in the population? Which attributes are required? How current must the information be? What level of error is tolerable? Who should be allowed to view or change it? These questions turn a vague request for data into a controlled information requirement.

• Relevant: connected to the decision being made.
• Reliable: sufficiently accurate, complete, and unbiased for that use.
• Timely: available before the decision loses value.
• Understandable: presented with definitions, units, and context.
• Verifiable: another knowledgeable person can trace or reproduce it.

1.3

Six components that must work together

AIS textbooks often list six components: people, procedures and instructions, data, software, information-technology infrastructure, and internal controls. The list is useful because failures often occur between components. A well-configured application cannot compensate for employees who share credentials. A strong approval policy cannot help if workflow rules route the transaction to the requester. Clean data will deteriorate if master-data responsibilities are unclear.

Think of the components as a chain of accountability. People perform and supervise work. Procedures define expected work. Data represent what happened. Software applies rules and transformations. Infrastructure keeps the service available and protected. Controls prevent, detect, and correct unacceptable outcomes. When investigating a problem, avoid blaming the visible software screen before considering the whole chain.

1.4

ERP integration: one model of the enterprise

An enterprise resource planning system integrates processes such as sales, purchasing, inventory, production, payroll, and financial reporting around shared data and configured rules. Integration reduces repeated entry and can make consequences visible quickly. When goods ship, the same event can update inventory, cost records, customer billing, and the general ledger rather than waiting for separate departments to reenter the transaction.

Integration does not mean every employee sees everything or that all modules are physically one program. It means the organization has designed consistent identifiers, relationships, workflows, and interfaces. The customer, product, vendor, and chart-of-accounts structures become shared organizational decisions. This is powerful because one approved change can flow everywhere. It is risky for exactly the same reason.

ERP implementation is therefore an accounting and control project, not only a technology project. Teams must decide how transactions are authorized, which fields are mandatory, when a document becomes an accounting event, how exceptions are handled, who can change configuration, and how converted data will be reconciled. Automating an unclear process usually makes the confusion move faster.

Source figure · Typical ERP modules

An ERP connects many processes around shared organizational data

1.5

The accountant’s role in system design

Accountants understand recognition, measurement, evidence, reconciliation, authorization, and accountability. Those ideas are system requirements. When a project team asks when revenue should post, how an approval threshold should work, or what evidence must survive a system change, the accountant is helping translate business meaning into data and control rules.

This role requires curiosity about operations. A journal entry is the compressed result of a longer process. To evaluate it, the accountant should be able to move backward to the subledger, source document, approval, and business event. The strongest AIS professionals can also move forward: they can explain how a change in a customer, product, or workflow field will affect reports, controls, and decisions.

2.1

The transaction-processing cycle

A transaction is an event that the organization chooses to record because it affects resources, obligations, performance, or control. Transaction processing usually includes data capture, validation, processing, storage, and output. These stages may occur within seconds, but separating them helps accountants locate failures.

Capture creates the initial record. Validation tests whether required fields, formats, relationships, quantities, and authorization conditions are acceptable. Processing applies business rules such as pricing, tax, depreciation, matching, or account determination. Storage preserves the event and its status. Output makes the result available through documents, dashboards, interfaces, and journal entries.

A rejected transaction is also important accounting evidence. If a sales order fails a credit check, the system should retain enough information to explain the exception, subsequent approval, and final outcome. Otherwise management sees only completed transactions and cannot evaluate the pressure placed on controls.

2.2

Source documents and business evidence

A source document provides evidence about a business event. It may be paper, electronic, or generated entirely inside a system. Examples include purchase requisitions, purchase orders, receiving reports, time records, sales orders, bills of lading, invoices, remittance advice, and bank confirmations. The important feature is not the visual format; it is the document’s role in establishing what happened, who participated, and when.

Different documents support different assertions. A customer purchase order supports the existence of demand but does not prove shipment. A carrier record supports dispatch but may not prove customer acceptance. An invoice shows billing, not cash collection. Accountants strengthen conclusions by matching complementary evidence rather than treating one document as proof of the entire transaction.

Electronic evidence needs identity and integrity controls. Useful metadata include creator, source system, timestamp, version, approval, status, and relationships to other records. A PDF saved without its workflow history may look authoritative while losing the information that made it reliable.

2.3

Batch and real-time processing

In batch processing, transactions accumulate and are processed together at a scheduled time. Payroll is a familiar example: approved time and employee data are collected, then gross-to-net calculations and payments are produced for the pay period. Batch processing can be efficient, predictable, and easier to control for high-volume periodic work.

In real-time processing, each accepted transaction updates relevant records immediately or nearly immediately. An online retailer may validate inventory and authorize payment while the customer waits. Real-time information can improve service and reduce stale data, but it demands high availability, carefully designed error handling, and controls that operate continuously.

Many systems are hybrid. A sale may reserve inventory immediately, settle card payments in a daily batch, and post summarized entries to the general ledger overnight. The accountant should understand the timing of each stage because cutoff, reconciliation, and availability risks follow the actual architecture rather than the label attached to the system.

2.4

Following an audit trail in both directions

An audit trail is the set of relationships and evidence that allows a user to connect a reported result to its underlying events and connect an event to its effects. Vouching begins with a recorded amount and moves backward toward source evidence. It is commonly associated with testing existence or occurrence. Tracing begins with source evidence and moves forward into records and reports. It is commonly associated with testing completeness.

The distinction is practical. Selecting revenue entries from the general ledger and finding invoices may show that recorded revenue has support, but it cannot identify shipments that were never invoiced or posted. To investigate completeness, the accountant needs a population that begins earlier in the process, such as shipping records, and traces those items forward.

Modern audit trails include more than document IDs. They may include event logs, interface message IDs, old and new values, automated rule results, user identities, and timestamps. Because administrators may have powerful access, logs should be protected from unauthorized alteration and monitored for gaps.

Source figure · Event-log architecture

Useful audit evidence must be collected, preserved, and searchable

2.5

Controls over input, processing, and output

Input controls help ensure that captured data are authorized, complete, and plausible. Examples include required fields, valid-value lists, check digits, format tests, reasonableness limits, duplicate checks, and batch control totals. Processing controls help ensure that rules execute completely and accurately. Examples include run-to-run totals, sequence checks, recalculation, interface acknowledgments, and exception logs. Output controls restrict distribution, identify report parameters, and ensure that recipients review the information.

No validation rule understands the business automatically. A reasonableness limit of $50,000 may detect an extra zero in ordinary purchases but block a legitimate equipment acquisition. The system therefore needs an exception path with appropriate approval and a record of the override. Controls should make unusual transactions visible without pretending that unusual means wrong.

2.6

System change is a controlled business event

Configuration changes, new interfaces, data conversions, and software releases can affect financial reporting even when no accounting policy changes. A small mapping change may redirect thousands of transactions. Change management therefore requires documented requests, impact analysis, testing, approval, migration controls, and post-implementation monitoring.

User acceptance testing should reflect real business scenarios, including exceptions and period-end conditions. Testing only the happy path can prove that the system works when everything is correct while revealing nothing about rejected transactions, overrides, reversals, duplicate messages, or failed interfaces. Accountants are valuable testers because they know which outcomes must reconcile.

3.1

Why a database is more than a large spreadsheet

A spreadsheet combines data, formulas, presentation, and user judgment in a flexible file. That flexibility is valuable for analysis, forecasting, and small controlled tasks. A database is designed to serve many users and applications while enforcing relationships, valid values, access rules, and durable transactions. It separates the stored facts from the many reports that can be built from them.

The difference matters when the data become operational. If thousands of users create orders while inventory, credit limits, approvals, and audit logs must remain consistent, one shared spreadsheet is not a reliable transaction system. If a controller wants to explore a 2,000-row export and test alternative assumptions, a spreadsheet may be the better tool. The goal is not to declare one superior; it is to match the tool to the responsibility.

A database management system also controls concurrency. Two users can attempt to update related records without silently overwriting one another. Transactions can commit as a complete unit or roll back when a required step fails. Those features support accounting integrity even though users rarely see them.

3.2

Entities, attributes, and keys

An entity is a distinguishable person, place, object, event, or concept about which the organization stores data. Customers, vendors, products, employees, sales orders, invoices, and payments are common entities. An attribute describes an entity: a customer has a name and credit limit; an invoice has a date and amount.

A primary key uniquely identifies each record in a table. The key should be stable and non-null. A foreign key stores the primary key of a related record, creating an enforceable relationship. The words primary and foreign describe roles, not importance. A customer ID is primary in the customer table and foreign in the sales-order table.

Keys represent business promises. A unique invoice ID promises that the organization can distinguish each invoice. A foreign-key constraint promises that an order cannot refer to a nonexistent customer. When a design relies on names instead of stable identifiers, spelling changes and duplicates can break those promises.

3.3

Relationships and business rules

Cardinality describes how many records of one entity can be associated with another. One customer can place many sales orders, while each sales order belongs to one customer. That is a one-to-many relationship. A sales order can contain many products, and a product can appear on many sales orders. That many-to-many relationship is resolved through an order-line table.

Optionality is equally important. Must every invoice relate to a sales order? Must every customer have at least one order? The answer depends on the business process. A database diagram should express these rules because they determine which records are valid and which exceptions deserve attention.

Accounting relationships are not always one-to-one. One cash receipt may settle several invoices, and one invoice may be paid through several receipts. A receipt-application table can represent that many-to-many relationship and preserve the amount applied to each invoice. Trying to place one receipt ID directly on the invoice would lose legitimate business cases.

Source figure · Entity-relationship model

A database diagram turns business rules into relationships

3.4

Normalization as disciplined fact storage

Normalization organizes data so that each fact is stored in an appropriate relation and harmful repetition is reduced. Students sometimes experience normalization as a collection of abstract rules. A more useful intuition is to ask: What does this fact describe, and where should it change? A vendor payment term describes the vendor relationship; the quantity received describes a specific receipt line.

Poor designs create update anomalies when the same fact must be changed in many rows, insert anomalies when one fact cannot be recorded without an unrelated event, and delete anomalies when removing one event accidentally removes a separate fact. Normalization reduces these contradictions by separating entities and connecting them through keys.

Normalization does not mean splitting data without limit. Reporting systems may intentionally use denormalized structures for speed and accessibility. The accounting question is whether the structure preserves definitions, lineage, and controlled transformation from the authoritative sources.

3.5

Master data, governance, and lineage

Master data describe relatively stable business objects such as customers, vendors, products, employees, locations, and accounts. Transaction rules rely on these records. A vendor bank account determines where cash goes. A product classification may determine tax and revenue reporting. An employee pay rate affects every subsequent payroll calculation.

Because master-data changes have repeated downstream effects, organizations assign ownership and stewardship. The owner is accountable for definitions, permitted use, and quality. A steward maintains standards and resolves issues. System controls restrict additions and changes, require evidence and approval, and log old and new values.

Data lineage explains where a value originated, how it was transformed, and where it was used. Lineage is essential when a reported balance appears wrong. Without it, teams may correct the final report while leaving the source field or transformation unchanged. With it, they can identify affected transactions, repair the source, rerun the process, and document the correction.

3.6

Operational databases and data warehouses

Operational databases support current business activity. They are optimized to enter orders, update inventory, record receipts, and maintain consistent transactions. Analytical repositories such as data warehouses integrate historical information from multiple sources and organize it for reporting and analysis.

Data are commonly extracted from source systems, transformed to standard definitions and formats, and loaded into the analytical environment. The process does not automatically resolve disagreements. If two divisions define active customer differently, combining their records produces a larger disagreement unless governance establishes a common definition or clearly preserves both.

Accountants should reconcile analytical outputs to authoritative sources and understand transformation logic. A dashboard total may be mathematically correct for the warehouse but still differ from the general ledger because of timing, currency conversion, excluded statuses, or mapping rules.

4.1

Define the output before writing the query

A strong query begins with a business specification, not a keyword. State what one output row should represent. Is it one row per invoice, customer, product, or month? Then identify the required fields, source entities, population criteria, calculation rules, and ordering. This output grain prevents accidental duplication and makes the query reviewable by someone who does not write SQL.

The phrase show me sales is not yet a specification. Does sales mean orders, shipments, recognized revenue, invoices, or cash receipts? Are canceled orders excluded? Which date defines the period? Are amounts gross or net of returns? SQL will execute an imprecise definition with perfect obedience, so the accountant must make the definition explicit first.

Treat a query like a small accounting policy. The SQL should reveal how the population and measurement were implemented, and the output should include identifiers that allow unusual rows to be traced to evidence.

4.2

SELECT, FROM, and WHERE

SELECT describes the columns or calculations to return. FROM identifies the table or joined tables that supply the rows. WHERE filters individual source rows before grouping. ORDER BY controls presentation but does not change which rows qualify. Reading a query in these logical pieces helps a reviewer connect syntax to the business definition.

Filters deserve special attention. Dates may include time components; text statuses may contain unexpected values; blank and null are not the same; and a condition on the wrong date can change cutoff. A query for invoices dated through June 30 answers a different question from a query for goods shipped through June 30.

SELECT invoice_id, customer_id, invoice_date, balance_due
FROM invoices
WHERE balance_due > 0
  AND invoice_date <= '2026-06-30'
ORDER BY balance_due DESC;

4.3

JOIN: connecting facts without copying them

A join combines related rows using a condition, usually a primary-key-to-foreign-key relationship. Customer names live in the customer table while invoices live in the invoice table. Joining through customer ID allows the report to display both without repeating the customer name in every stored invoice record.

The most important join risk is an unexpected relationship. If one invoice has five line items, joining invoice headers to lines produces five rows for that invoice. Summing the header amount after the join multiplies it by five. The SQL may run without error while the accounting result is materially wrong.

Before joining, state the expected cardinality and test it. Count rows before and after the join, look for unmatched keys, and verify whether the output grain changed. A technically valid join is not automatically a valid accounting analysis.

Source figure · SQL join patterns

A join rule determines which unmatched rows remain

SELECT c.customer_id, c.customer_name,
       i.invoice_id, i.balance_due
FROM customers AS c
JOIN invoices AS i
  ON i.customer_id = c.customer_id
WHERE i.balance_due > 0;

4.4

Aggregation and groups

Aggregate functions summarize rows. SUM adds amounts, COUNT measures records, AVG calculates a mean, and MIN or MAX identifies extremes. GROUP BY defines the categories for which summaries are produced. Every selected field that is not aggregated normally belongs in the grouping definition.

WHERE filters source rows before aggregation. HAVING filters groups after aggregation. If the task is to find customers whose total open balance exceeds $25,000, WHERE first restricts the population to open invoices and HAVING then evaluates each customer’s grouped total.

Reconcile aggregates. A summary by region should tie to the same population summarized without region unless there is a documented category such as unknown or intercompany. A grand total that does not reconcile is a diagnostic signal, not a formatting inconvenience.

SELECT customer_id,
       SUM(balance_due) AS total_open_balance,
       COUNT(*) AS open_invoice_count
FROM invoices
WHERE balance_due > 0
GROUP BY customer_id
HAVING SUM(balance_due) > 25000
ORDER BY total_open_balance DESC;

4.5

Outer joins and missing relationships

An inner join returns only rows with matches on both sides. That is useful when matched records define the population, but it can silently remove the exceptions an accountant cares about. A left join keeps every row from the left table and shows null values when a related row is absent.

Exception-oriented queries deliberately search for missing relationships: shipments without invoices, purchase orders without receipts, employees without approved time, or journal entries without preparer information. The absence of a record becomes the evidence under investigation.

Null requires careful interpretation. It can mean not applicable, unknown, not yet recorded, or lost during an interface. The query identifies the condition; process knowledge determines what the condition means and whether it is acceptable.

SELECT s.shipment_id, s.order_id, s.ship_date
FROM shipments AS s
LEFT JOIN invoices AS i
  ON i.order_id = s.order_id
WHERE i.invoice_id IS NULL;

4.6

Controls over analytical SQL

A query used for a key report or control should be treated as controlled logic. Document its purpose, owner, data sources, parameters, expected grain, and reconciliation. Restrict changes, review code, test edge cases, and retain the version used for important decisions. A saved query name is not sufficient documentation if the underlying logic can change without evidence.

Completeness and accuracy depend on more than syntax. The source extract may be incomplete, the join may omit records, the filter may use the wrong date, or the user may run the query against a test environment. Useful output identifies the as-of date, source, parameters, and run time so another person can understand what was produced.

Source figure · SQL statement anatomy

SQL can change records as well as read them

5.1

A disciplined language for risk

A threat is a potential source of harm, such as a dishonest employee, phishing campaign, fire, or software defect. A vulnerability is a weakness that a threat can exploit, such as shared credentials, unpatched software, or an unverified change process. A risk event is the occurrence itself. Impact is the consequence to operations, reporting, compliance, assets, or reputation.

Separating these ideas improves control design. Saying cyber risk is too broad to guide action. Saying a phished accounts-payable employee could expose credentials that allow an attacker to change vendor bank data and redirect payments identifies the actor, weakness, event, and consequence. The organization can then choose controls at several points in the chain.

Risk assessment considers likelihood and impact, but the numbers are estimates rather than facts. Low-frequency events may deserve strong controls when the potential loss is catastrophic. Management also considers velocity, persistence, detectability, and interdependence with other risks.

5.2

Prevent, detect, correct, and recover

Preventive controls attempt to stop an unacceptable event before it occurs. Segregation of duties, approvals, access restrictions, and input validation are examples. Detective controls identify events that occurred or conditions that may indicate a problem. Reconciliations, exception reports, log monitoring, and physical counts are common examples.

Corrective controls repair identified errors or weaknesses, while recovery controls restore operations and data after disruption. The categories can overlap. A backup supports recovery, but testing the restore process is a detective control over whether the backup actually works. A control portfolio is stronger when it does not depend on one mechanism or one person.

Control design should specify the risk, control owner, frequency or trigger, evidence, investigation method, and escalation path. “Management reviews reports” is not a complete control description. Which report, for what, using what criteria, and what happens when the reviewer finds an exception?

5.3

Fraud changes the control problem

Error is unintentional; fraud involves intentional deception. Both can misstate records, but fraud is harder to control because the actor may understand and circumvent normal procedures. Collusion can defeat segregation of duties, and managers may override controls designed for subordinates.

The fraud triangle describes pressure or incentive, opportunity, and rationalization. It is not a formula that predicts a dishonest person. For system design, opportunity is especially actionable. Excessive access, weak review, opaque estimates, missing audit logs, and a culture that rewards results without questioning methods can increase opportunity.

Fraud detection requires skepticism about patterns and explanations. A valid approval does not prove the approver was independent. A three-way match does not protect a fictitious vendor if one employee created the vendor, purchase order, and receipt. Controls should consider how records could be made to agree falsely.

Source figure · Fraud triangle

Fraud risk is often examined through pressure, opportunity, and rationalization

5.4

Confidentiality, integrity, and availability

Confidentiality means information is accessible only to authorized parties. Integrity means data and processing are complete, accurate, authorized, and protected from improper change. Availability means systems and information are accessible when needed. AIS security decisions often involve all three.

Encryption can protect confidentiality in transit or storage, but it does not prove that the sender was authorized to change a vendor. A digital signature can support origin and integrity, but it does not make false content true. Backups support availability and recovery, but they are useful only if protected, current, and restorable.

Least privilege gives users only the access needed for their responsibilities. Access should be approved, periodically reviewed, and removed promptly when roles change. Privileged accounts deserve additional monitoring because they can alter configurations, users, and logs.

Source figure · NIST Cybersecurity Framework 2.0

Cybersecurity risk management connects six functions

5.5

IT general controls and application controls

IT general controls support the environment in which applications operate. Major areas include access management, program change, computer operations, backup and recovery, and system development. Application controls operate within a particular process or program, such as a credit-limit check, duplicate-invoice test, three-way match, or automated account mapping.

The distinction matters because a perfectly configured application control can become unreliable if administrators can change its logic without approval or if access allows users to bypass it. Conversely, strong general controls do not guarantee that a particular business rule is designed correctly.

Automated controls can be consistent and efficient, but their reliability depends on configuration, input data, interfaces, and the general control environment. Testing often includes understanding the rule, testing relevant configurations and access, evaluating changes, and verifying that the control operated on a complete population.

5.6

Third parties do not transfer accountability

Cloud providers, payroll processors, payment platforms, and other service organizations may perform important AIS activities. Outsourcing changes who operates the control; it does not remove management’s responsibility for its process, financial statements, compliance, or customer commitments.

Management should understand the service scope, access model, data location, incident responsibilities, recovery commitments, and controls that the customer must perform. Independent assurance reports can provide useful evidence about the provider, but they must be read for period, scope, exceptions, subservice organizations, and complementary user-entity controls.

A provider may calculate payroll accurately while the customer remains responsible for approved employee data. If Northstar fails to remove terminated employees, a clean report over the processor does not correct Northstar’s input failure.

6.1

Think in cycles, not isolated entries

A transaction cycle groups recurring activities that accomplish a business purpose. The revenue cycle converts customer demand into delivery and collection. The expenditure cycle converts organizational needs into acquired goods or services and payment. Each cycle crosses departments, systems, and accounting records.

Cycle thinking helps accountants understand cause and evidence. Accounts receivable is not created by the general ledger team; it emerges from customer setup, order acceptance, fulfillment, billing, and posting. Accounts payable depends on need identification, vendor selection, ordering, receipt, invoice processing, and payment. An error near the beginning can flow through every later record.

A useful process analysis identifies activities, actors, documents, data, decisions, risks, controls, and accounting effects. Flowcharts are valuable when they make handoffs and responsibilities visible rather than merely decorating a list of steps.

6.2

Order to cash

The revenue cycle commonly includes customer setup, sales-order entry, credit approval, inventory allocation, picking, shipping, billing, accounts-receivable maintenance, cash collection, and returns. Organizations combine or automate activities differently, but the economic sequence remains useful.

Important risks include accepting orders from invalid or poor-credit customers, using unauthorized prices, shipping the wrong goods, recording fictitious or premature revenue, failing to bill shipments, misapplying cash, and concealing theft through write-offs. The strongest controls are positioned where they can prevent or expose the specific failure.

The system should retain status transitions. An order might be entered, approved, partially shipped, backordered, billed, disputed, returned, and closed. Replacing status history with only the current status weakens cutoff analysis and makes it harder to explain exceptions.

6.3

Procure to pay

The expenditure cycle usually begins with a need. An authorized requisition leads to vendor selection and a purchase order. Receiving records what arrived. Accounts payable evaluates the vendor invoice against authorized terms and receipt evidence. Treasury or another authorized function releases payment, and accounting records the liability and cash effect.

A three-way match compares the purchase order, receiving record, and vendor invoice. It addresses whether the organization ordered the goods, received them, and was billed consistently. Tolerances may permit small differences, but tolerance design should reflect risk, materiality, and the possibility of transaction splitting.

Not all purchases fit a physical-goods process. Utilities, rent, professional services, subscriptions, and recurring charges may lack a receiving document. The organization needs alternative evidence, such as a contract owner’s service confirmation, usage record, milestone approval, or controlled recurring-payment schedule.

Source figure · Procure-to-pay process

One purchase becomes several related records before cash leaves

6.4

Segregation of duties

Segregation of duties separates incompatible responsibilities so that one person cannot both commit and conceal an error or fraud. The classic categories are authorization, custody of assets, recording, and independent reconciliation. In digital systems, configuration and privileged access can also create powerful combinations.

Perfect separation is not always possible, especially in smaller organizations. Management can add compensating controls such as detailed owner review, bank alerts, restricted transaction limits, independent reconciliations, or external support. The compensating control must address the actual combination of access rather than merely add another signature.

Role design should consider what users can accomplish across applications. An employee may lack payment approval in the ERP but have access to change vendor data and release files on the banking platform. Reviewing each system separately can miss the combined capability.

6.5

From process failure to financial-statement assertion

Financial-statement assertions translate broad reporting risk into testable claims. Existence or occurrence asks whether recorded assets, liabilities, and transactions are real. Completeness asks whether required items were recorded. Rights and obligations considers ownership and responsibility. Valuation and allocation considers appropriate amounts. Cutoff considers the correct period. Presentation and disclosure considers classification and explanation.

The same process supports several assertions through different controls. Prenumbered shipping documents and investigation of sequence gaps can support completeness. Matching invoices to shipping evidence can support occurrence. Comparing dates can support cutoff. Reviewing prices, quantities, returns, and collectibility can support accuracy and valuation.

Avoid matching one control mechanically to one assertion. Start with how the process could produce a misstatement, then evaluate whether the control prevents or detects that path with sufficient precision.

6.6

Event logs and process mining

Process mining uses event-log data to reconstruct how transactions actually moved through a process. A useful log normally includes a case identifier, activity, timestamp, and often the user or system performing the activity. The analysis can reveal rework, skipped approvals, unusual sequences, long delays, and variants that a formal flowchart omits.

The method depends on data quality and interpretation. A missing event may mean the activity did not occur, occurred outside the system, or was not logged. A rare process variant may be fraud, a legitimate emergency, or a data error. Accountants combine event patterns with documents, interviews, and control knowledge.

Process mining is especially valuable for population-level questions. Instead of sampling a few purchase orders to see whether approval preceded receipt, the analyst can test the ordering of timestamps across the full logged population and investigate exceptions.

7.1

Pay the right person the right amount

Payroll brings together employee master data, time and attendance, compensation rules, benefits, taxes, deductions, payment instructions, and general-ledger mappings. The process handles valuable and confidential data, repeats frequently, and often relies on a service provider. Small master-data errors can recur across many pay periods.

A typical cycle includes authorized hiring, employee setup, time capture, supervisor approval, gross-to-net calculation, payroll review, payment, liability remittance, posting, and reconciliation. Salaried and hourly employees create different risks, but both depend on valid employees and authorized compensation.

Key controls include independent approval of hires and pay changes, restricted master-data access, review of change reports, reasonableness comparisons to prior payroll, segregation of preparation and release, bank reconciliation, and timely removal of terminated employees.

Source figure · Payroll process map

Payroll joins employee data, time evidence, calculations, approvals, and payment

7.2

Time, pay rates, and direct-deposit changes

Time records establish labor effort and may affect payroll, job cost, inventory, customer billing, and project profitability. Supervisory approval should demonstrate knowledge of the work, not become a routine click. Automated checks can flag duplicate time, impossible hours, missing schedules, or entries after termination.

Pay-rate and bank-account changes are high-risk master-data events. Independent notification can help detect account takeover: when direct-deposit information changes, the system notifies the employee through a previously established channel. Sensitive changes close to payroll should receive heightened review or a controlled waiting period.

Reasonableness analytics are useful but should be interpreted. A large increase may indicate an error, bonus, retroactive adjustment, or legitimate overtime. The control must connect the exception to authoritative approval and document the conclusion.

7.3

Production and inventory cost

The production cycle plans what to make, authorizes work, issues materials, records labor and machine activity, reports completed units, and updates inventory and cost records. Bills of materials, routings, work orders, material requisitions, move tickets, and production reports are key evidence.

Standard costs translate expected quantities and rates into a benchmark. Actual activity creates price, usage, rate, and efficiency differences. A variance is a signal for explanation, not automatically an error or poor performance. The underlying data and business conditions determine its meaning.

Controls address unauthorized production, theft of materials, inaccurate bills of material, fictitious completion, unrecorded scrap, and improper overhead allocation. Physical counts and cycle counts compare records with assets, while investigation connects differences to receiving, production, shipping, or master data.

7.4

The general ledger is a hub, not the origin

The general ledger summarizes financial effects from subledgers and journal entries. It supports trial balances, financial statements, consolidations, and management reporting. Because it compresses detail, investigators often move from a general-ledger account to a subledger and then to source events.

Interfaces may post every transaction or summarized batches. Summary posting improves efficiency but increases the importance of control totals and drill-down evidence. The ledger total should reconcile to the contributing subledger, and the subledger should reconcile to authoritative operational records where appropriate.

Manual journal entries are necessary for estimates, allocations, corrections, and transactions not produced by subledgers. Their flexibility creates risk. Controls commonly address preparer and approver independence, supporting documentation, account eligibility, period, unusual users, late entries, round amounts, and post-close activity.

7.5

The financial close as a controlled process

The close coordinates subledger completion, reconciliations, estimates, journal entries, consolidation, review, financial-statement preparation, and disclosure. A close checklist is useful only if tasks have clear owners, dependencies, evidence, due dates, and escalation for unresolved differences.

Account reconciliations connect ledger balances to independent or detailed support. A strong reconciliation identifies the population, explains reconciling items, assigns action, and documents review. Carrying the same unexplained difference each month is not resolution.

Management review controls rely on the reviewer’s knowledge and precision. A review of gross margin can detect a large unexpected change if expectations are quantified, disaggregated appropriately, and supported by investigation. A signature without evidence of criteria or follow-up provides little assurance.

7.6

Spreadsheets and end-user computing

Spreadsheets often bridge systems during budgeting, tax, valuation, consolidation, and the close. They are powerful because users can build logic quickly. The same flexibility allows hard-coded values, broken formulas, hidden rows, uncontrolled versions, and accidental overwrites.

The level of control should reflect the spreadsheet’s importance and complexity. Key controls may include assigned ownership, input-source reconciliation, locked formulas, change review, version naming, access restriction, reasonableness tests, independent reperformance, and retention of the final approved file.

A spreadsheet control is not simply checking that cells contain formulas. The reviewer should understand the model’s purpose, significant assumptions, data lineage, formulas, outputs, and sensitivity. A technically correct formula can implement the wrong accounting judgment.

8.1

Begin with the decision, not the tool

Descriptive analysis asks what happened. Diagnostic analysis asks why it happened. Predictive analysis estimates what may happen. Prescriptive analysis recommends an action under assumptions and constraints. A single project may move through all four, but the question should be clear at each stage.

An attractive visualization does not repair a vague question. “Analyze expenses” leaves the population, time period, benchmark, and desired action unspecified. “Identify employee expense claims in the second quarter that violate policy or resemble prior duplicates so reviewers can prioritize investigation before reimbursement” is operational and testable.

Accountants should also define the unit of analysis. One row per claim, employee, vendor, or day can produce different patterns. Changing units during analysis without noticing can create misleading counts and averages.

Source figure · CRISP-DM process

An analytics project is iterative, not a straight path from data to answer

8.2

Quality is fitness for purpose

Common dimensions include completeness, accuracy, validity, consistency, uniqueness, and timeliness. A field may be valid in format but inaccurate in meaning. A date of 2026-02-28 passes a format test; it may still be the wrong invoice date. Data quality must be assessed against the intended decision and authoritative evidence.

Missing values require interpretation. Zero, blank, unknown, not applicable, and not yet available are different states. Replacing all blanks with zero can transform uncertainty into a false fact. The cleaning decision should be documented and, where possible, preserve the original value and a reason code.

Duplicate records are also contextual. Two identical payment rows may represent a duplicate extract, a repeated payment, or two legitimate installments. The analyst uses identifiers, timestamps, source-system knowledge, and supporting evidence before deleting anything.

8.3

A reproducible preparation workflow

Preserve the raw data. Work on a controlled copy or use code and query steps that can be rerun. Profile fields before changing them: count records, inspect types and unique values, calculate missingness, test ranges, and reconcile totals. Then standardize, validate, join, derive, and document.

Each transformation should have a business reason. Standardizing OH, Ohio, and ohio to one state code may be appropriate. Converting a numeric-looking customer ID to a number may be destructive if leading zeros carry meaning. Trimming spaces may be safe for a name but not for a hashed value.

Keep an exceptions table rather than silently dropping records. A failed date, unmatched vendor, or negative quantity may be the most important observation. The final dataset should reconcile to the starting population through retained, excluded, and unresolved categories.

8.4

A number’s appearance does not reveal its meaning

Nominal data represent categories without order, such as payment method. Ordinal data have an order but not necessarily equal distances, such as risk ratings. Interval measures have meaningful differences but no true zero, while ratio measures have a meaningful zero. The measurement level affects valid comparisons and calculations.

Accounting datasets contain identifiers that look numeric. Vendor 00147 is not smaller than vendor 00920 in an economic sense. Averaging account numbers is meaningless. Conversely, categorical text may encode business order, such as low, medium, and high risk. Analysts must understand the construct, not infer it from file format.

Operational proxies also deserve skepticism. Number of login events may be used as a proxy for system activity, but automated integrations and shared service accounts can distort it. Before modeling, ask whether the measured field represents the concept the analysis claims to study.

8.5

Explore distributions before trusting summaries

Exploratory data analysis uses counts, distributions, relationships, and visualizations to understand the data before formal modeling. Start with population size, missing values, duplicates, ranges, central tendency, spread, and time patterns. Segment results by meaningful business dimensions.

Means are sensitive to extreme values, while medians describe the middle observation. Neither is universally better. A few very large invoices may be exactly where material risk is concentrated. Outliers should be investigated, not automatically removed.

Time is often a hidden variable. A relationship across the full year may reflect seasonality, a system conversion, or a policy change. Plotting values over time and marking known events can distinguish enduring patterns from one-time transitions.

8.6

Lineage and evidence for analytics

A defensible analysis identifies data sources, owners, extraction methods, time periods, filters, joins, transformations, assumptions, and known limitations. This lineage allows another person to reproduce the result and evaluate whether the population matches the decision.

Analytical work often moves through several tools. A query extracts ERP data, a spreadsheet maps categories, a script calculates features, and a dashboard displays results. Each handoff can change meaning. Control totals, versioning, code review, and retained parameter files connect the chain.

Documentation is not paperwork added after analysis. Writing down the intended grain and definition often reveals mistakes before the result is produced. For significant decisions, the evidence should allow a reviewer to move from the chart back to the underlying records.

9.1

Linear regression as a compact relationship

Linear regression describes how an outcome tends to change with one or more predictors. In a simple model, the intercept is the predicted outcome when the predictor is zero, and the slope is the predicted change in the outcome for a one-unit increase in the predictor. Interpretation must respect units and the range of observed data.

A fitted line summarizes variation; it does not explain every observation. Residuals are the differences between actual and predicted values. Their size and pattern help reveal poor fit, missing nonlinear relationships, changing variance, and unusual observations.

Accounting applications include cost estimation, sales forecasting, allowance analysis, and analytical procedures. The model is evidence, not an automatic conclusion. The accountant evaluates data quality, assumptions, business changes, and whether the relationship is stable enough for the intended use.

Figure 9.1 · Regression residuals

A residual is the vertical gap between an observation and its fitted value

9.2

Prediction is not causation

A predictor can improve forecasts without causing the outcome. Late-night journal entries may be associated with errors because unusual adjustments occur during stressful closes. The timestamp itself may not cause the error. Staffing, complexity, deadline pressure, and entry type may drive both.

Causal claims require a credible explanation of what would have happened under an alternative action. Confounding variables, reverse causality, selection, and measurement choices can make an association misleading. Accountants should use careful language: associated with, predicts, or is consistent with are not the same as causes.

This distinction affects control decisions. Blocking every late-night entry might disrupt legitimate close activity without addressing poor planning or complex estimates. A predictive alert can prioritize review even when the causal mechanism remains uncertain.

9.3

Classification predicts categories

Classification assigns observations to categories or estimates the probability of a category. Examples include likely duplicate versus not duplicate, high-risk versus ordinary journal entry, or likely late payment versus likely on-time payment. Many models produce a score or probability that must be converted into action through a threshold.

The target label must be meaningful. Historical investigation outcomes may be incomplete or biased toward transactions that previous rules selected. A model trained on detected fraud learns the detection process as well as the underlying behavior. Missing labels do not necessarily mean negative cases.

Class imbalance is common. If only 0.2% of payments are fraudulent, a model that predicts no fraud is 99.8% accurate and completely useless for detection. Evaluation must focus on the costs and benefits of errors, not headline accuracy.

9.4

How a decision tree partitions data

A decision tree asks a sequence of questions that divide observations into increasingly similar groups. A payment-risk tree might first ask whether vendor bank data changed recently, then whether the change received independent verification, then whether the payment exceeds a threshold. Each path ends in a prediction or score.

Trees are appealing because their paths can be explained, but a displayed tree may still be unstable or overly complex. Small data changes can produce different splits. Deep trees can memorize training cases, including noise. Pruning, minimum leaf sizes, and validation help control complexity.

The split criterion measures how much a candidate question reduces impurity or uncertainty. Students do not need to worship the formula to understand the logic: a useful split creates child groups that are more decisive about the target than the parent group.

Figure 9.2 · Learned decision tree

A tree partitions cases one question at a time

9.5

Learn on one set; judge on unseen cases

Training data are used to estimate model parameters or rules. Validation data support model selection and threshold tuning. Test data provide a final estimate of performance on cases not used in development. Repeatedly checking the test set while redesigning the model leaks information and makes the final estimate optimistic.

Random splitting may be inappropriate when time or related records matter. Training on later transactions and testing on earlier ones does not resemble future use. Placing invoices from the same vendor in both sets can allow vendor-specific patterns to leak across the split. Time-based and group-based validation can better represent deployment.

Performance can deteriorate when business processes, customer behavior, systems, or fraud strategies change. Ongoing monitoring compares data and outcomes with the development environment and defines triggers for investigation, recalibration, or retirement.

Source figure · Training and test comparison

A model that fits training data best may generalize worst

9.6

Model output is one item of evidence

A high-risk score does not prove fraud, and a low-risk score does not prove legitimacy. The score prioritizes or informs a decision under assumptions. Human reviewers need relevant source evidence, understandable reason codes where feasible, and authority to disagree.

Evaluation should include technical performance and process performance. Does the model improve detection or efficiency? Can reviewers act on the output? Are alerts timely? Are investigations consistent? Do errors concentrate in particular groups or transaction types? Can the organization document and challenge the system?

A model control includes ownership, approved purpose, data and version lineage, performance thresholds, access, change procedures, monitoring, and incident response. Without these surrounding controls, even a strong model can produce an unreliable business process.

10.1

Logistic regression estimates bounded probabilities

Logistic regression connects predictors to the log-odds of a binary outcome and transforms the result into a probability between zero and one. Unlike a linear probability model, it cannot predict a probability below zero or above one. The coefficients are not direct percentage-point effects without further calculation.

For most accounting users, the key interpretation is conditional: given the model, data, and features, this observation received an estimated probability. The estimate is not personal certainty and may be poorly calibrated. If cases scored near 0.70 experience the outcome only 0.35 of the time, the ranking may still be useful while the probability interpretation is misleading.

Features should be available at decision time. A model that predicts late payment using a field entered only after collection has leaked future information. It will appear powerful in testing and fail in actual use.

Source figure · Logistic probability curve

Logistic regression converts an unbounded score into a probability

10.2

The confusion matrix makes errors visible

A true positive is a positive case correctly flagged. A true negative is a negative case correctly cleared. A false positive is an ordinary case flagged, creating unnecessary review or interruption. A false negative is a positive case missed, allowing the risk to pass. Both error types matter, but their consequences differ.

Precision asks: among flagged cases, what proportion were actually positive? Recall asks: among actual positive cases, what proportion were flagged? Specificity measures the proportion of negative cases correctly cleared. The appropriate emphasis follows the decision.

Metrics should be paired with volumes. A precision of 20% may sound low, but if manual review previously found one issue in 500 cases, finding one in five may be operationally valuable. Conversely, even high recall may create more alerts than the team can investigate.

Figure 10.1 · Confusion matrix

Classification performance is a table of actual and predicted outcomes

10.3

A threshold is a policy decision

A probability model ranks cases; a threshold converts scores into categories or actions. Lowering the threshold usually catches more positive cases and creates more false positives. Raising it usually reduces review volume and misses more positives. There is no universally correct threshold.

The threshold should reflect error costs, review capacity, control alternatives, materiality, and customer or employee consequences. Some systems use tiers: block the highest-risk events, route a middle group for review, and allow lower-risk events while monitoring the population.

Thresholds should be approved, documented, and monitored. If teams quietly increase the threshold because alerts are burdensome, the control’s effective precision changes without formal risk acceptance.

Source figure · ROC curve

Each point on an ROC curve represents a different classification threshold

10.4

Clustering finds groups without a target label

Clustering groups observations based on similarity when no known outcome label guides learning. It can help segment customers, vendors, transactions, or operating locations. The algorithm does not discover natural truth; it creates groups from selected features, scales, distance definitions, and the requested number or structure of clusters.

Feature preparation strongly influences the result. Dollar value can dominate a distance measure if other features are small percentages. Standardization may give variables more comparable influence, but it also embeds a judgment that one standard deviation in each feature should matter similarly.

Clusters require interpretation and validation. A cluster is not automatically high risk or a market segment. Analysts inspect its characteristics, stability, business meaning, and usefulness. Naming a cluster after seeing its average features is a human interpretation, not an output produced by mathematics alone.

Figure 10.3 · K-means clustering

Discovered clusters are not automatically the same as real-world categories

10.5

Similarity is a modeling decision

Euclidean distance measures straight-line separation across numeric features. Other measures can handle categories, binary attributes, or differently shaped relationships. The choice defines what similar means. Transactions close in dollar value may differ completely in vendor, geography, timing, or approval path.

Scaling can prevent a large-unit feature from dominating. Suppose invoice amount ranges to $1,000,000 while approval-delay days range from zero to ten. Without scaling, amount will usually dominate Euclidean distance. With scaling, delay may receive far more influence. Neither choice is neutral.

Feature selection should connect to the analysis purpose and be reviewed for proxies. Geography, schedule, or job-related attributes can reflect protected or sensitive characteristics. Even an unsupervised method can create consequential groups that deserve fairness and governance review.

Source figure · Silhouette analysis

Cluster separation can be inspected instead of accepted on appearance alone

10.6

Evaluate the whole decision system

Technical metrics describe model behavior on labeled data. Business evaluation asks whether the complete workflow improves outcomes compared with the current process. Measure alert volume, investigation time, confirmed findings, prevented loss, delayed legitimate activity, user overrides, and downstream corrections.

A model can improve one metric while harming the system. Higher recall may overwhelm reviewers, causing alerts to age until they are no longer useful. A cluster analysis may produce insightful segments that no business process can act upon. A calibrated probability may still rely on prohibited or unavailable data.

Before deployment, define success, unacceptable outcomes, fallback procedures, monitoring, and ownership. After deployment, compare actual results with those expectations and retain the ability to change or stop the system.

11.1

Generating one token at a time

A large language model processes text as tokens, which may be words, pieces of words, punctuation, or other symbols. Given a sequence of tokens, it estimates a probability distribution for what token could come next. It selects a token, adds it to the sequence, and repeats. Complex responses emerge from this repeated prediction process.

The model does not retrieve a complete answer from a hidden filing cabinet. Its parameters encode patterns learned during training. This enables flexible language, summarization, transformation, and reasoning-like behavior. It also explains why the model can produce fluent statements that are unsupported or false.

Generation settings influence variability. More deterministic settings favor high-probability continuations; more exploratory settings increase variation. Neither setting creates truth. Reliability depends on task design, evidence, tools, verification, and control.

11.2

Embeddings and attention

Embeddings represent tokens or other items as vectors whose positions capture learned relationships. Similarity in this space can support search, classification, and retrieval. The representation is mathematical and contextual; it is not a dictionary definition or a guarantee that two items are equivalent for accounting purposes.

Attention allows the model to weigh relationships among tokens in the current context. It helps connect pronouns, instructions, examples, figures, and distant parts of a document. Attention is a mechanism for combining context, not a human spotlight or proof of comprehension.

In practice, embeddings can retrieve potentially relevant policy passages or group similar transactions. The retrieved items still require authorization, completeness, and interpretation. Similar wording may describe a different jurisdiction, period, or accounting policy.

Source figure · Transformer architecture

Attention operates inside a larger transformer architecture

11.3

Training and adaptation

Pretraining exposes a model to large collections of data and teaches broad language patterns through prediction. Subsequent instruction tuning or other adaptation can make responses more useful for following requests. Preference-based methods can further shape behavior toward desired qualities.

Training is different from the prompt and documents supplied during a conversation. The model’s parameters usually do not change when a user adds a policy to the context. The model uses the temporary context to produce the current response. This distinction matters when organizations discuss updating, grounding, or retaining information.

Training data are imperfect, historically situated, and often difficult to inspect completely. Models can reproduce biases, outdated assumptions, or common misconceptions. An organization should not assume that general training contains its private policy or current authoritative guidance.

11.4

Context is limited working material

The context window contains the current instructions, conversation, retrieved material, and generated text that the model can use at one time. Longer context can include more evidence, but more is not always better. Irrelevant or conflicting documents can distract the model, and important details can be difficult to use consistently across very long inputs.

Good context construction selects authorized, relevant, and current material; preserves useful structure; and tells the model how to handle conflicts and missing evidence. Chunking a document can improve retrieval but may separate a sentence from definitions, exceptions, or tables that determine its meaning.

The system should distinguish model context from authoritative storage. A chat transcript is not automatically an accounting workpaper, records repository, or approved decision log. Required evidence and approvals should be stored in controlled systems.

11.5

Multimodal and reasoning-oriented systems

Contemporary generative systems may accept several forms of input: text, images, audio, spreadsheets, diagrams, and combinations of them. Multimodal capability matters in accounting because evidence rarely arrives as clean paragraphs. An invoice has layout, a lease contains tables, a warehouse photograph contains visual evidence, and a meeting recording contains spoken statements. A system may connect these modes, but each mode introduces its own extraction and interpretation errors.

Reasoning-oriented models use additional computation during response generation to work through multi-step tasks. They may plan intermediate steps, test candidate approaches, use tools, or revise an answer before presenting it. This can improve performance on difficult analysis, code, and mathematics. It does not turn the response into an audit trail or guarantee that the reasoning used all relevant evidence. The visible explanation may be a useful summary without being a complete record of the model's internal computation.

For accountants, the practical question is what evidence entered the system and what controlled operation produced each material result. If a model reads an invoice image, preserve the original image, extracted fields, confidence or exception indicators, validation results, and reviewer changes. If a reasoning model uses a calculator or database, preserve the tool call and result rather than relying only on the final prose.

11.6

Match the model to the task

Language models are well suited to drafting, summarizing, classifying text, extracting candidate fields, explaining concepts, and transforming formats when outputs can be reviewed. They are less appropriate as the sole authority for exact calculations, current rules, irreversible actions, or conclusions requiring complete and verifiable evidence.

Many useful workflows combine deterministic systems and generative models. A database calculates balances, a rule engine enforces authorization, a retrieval service supplies policies, and a language model drafts an explanation. The model contributes flexibility while controlled components preserve exactness.

Task decomposition often improves reliability. Instead of asking for a complete technical accounting memo in one step, the system can identify relevant facts, retrieve approved guidance, map facts to criteria, draft the analysis, check citations, and route the result to a qualified reviewer.

11.7

Separate the model from the AI system

A model is one component. A deployed AI system may also include system instructions, retrieval indexes, access rules, tools, memory, application code, user interfaces, monitoring, and human review. Two products using the same underlying model can therefore behave very differently. One may search an approved policy library and show citations; another may answer from general patterns with no source control.

This distinction makes evaluation more durable. Model rankings change quickly, but accountants can continue asking stable system questions: What is the authorized source? Which user identity and permissions apply? What may the system change? How are versions and actions logged? How is insufficient evidence handled? Who reviews the output and owns the final decision?

It also helps assign responsibility. A provider may develop a general model, a software vendor may create the application, and Northstar may select the data, configure permissions, and decide how output affects an employee or customer. Governance should attach controls and accountability to each layer instead of describing every failure as 'the AI made a mistake.'

Source figure · Retrieval-augmented generation

RAG is a system around a language model, not a fact stored inside it

• Model layer: learned parameters and inference behavior.
• Context layer: instructions, conversation, retrieved documents, and temporary working material.
• Tool layer: databases, calculators, search, files, and external actions.
• Application layer: permissions, interface, validations, logging, and workflow rules.
• Organization layer: purpose, policy, review, accountability, monitoring, and consequences.

11.8

Fluency, uncertainty, and evidence

Language models are optimized to produce likely continuations, not to communicate calibrated uncertainty automatically. A response can sound equally confident when it is supported, uncertain, or invented. Asking the model to be careful may improve behavior, but it is not a control equivalent to evidence.

Grounded systems make source material available and require output to connect claims to that material. Evaluation tests whether citations actually support claims, whether important evidence was omitted, and whether the system appropriately declines when evidence is insufficient.

Accountants should treat model output as a work product with provenance. Record the model or system version where relevant, prompt or instructions, source documents, key parameters, reviewer, changes, and final decision. The level of documentation should match the significance of the use.

12.1

Make the task observable

A useful prompt identifies the role or perspective, objective, audience, relevant facts, authorized sources, constraints, and desired output. It also states what to do when evidence is missing or conflicting. The goal is not elaborate wording; it is a testable job description.

Separate instructions from data. Clearly delimit a contract, policy, email, or ledger extract so text inside the source is not mistaken for a system instruction. Specify whether the model may use general knowledge or only supplied evidence. For consequential work, require source links or citations at the claim level.

Output criteria make review easier. A request for a concise memo should define the sections, decision standard, tables, and uncertainty disclosures. Structured output can support downstream validation, but a valid format does not ensure correct content.

12.2

Examples teach the pattern in context

Few-shot prompting provides examples of inputs and desired outputs. Examples can clarify labels, tone, reasoning structure, and edge cases without changing model parameters. Their wording and order can influence the response, so examples should be representative and reviewed.

Examples can also introduce bias. If every high-risk example involves a new vendor, the model may overuse that feature even when other evidence matters. Include difficult negative examples, exceptions, and cases where the correct response is insufficient information.

Do not include confidential real records casually. Use authorized, minimized, or synthetic examples consistent with organizational policy. Treat prompts and example libraries as controlled content when they shape important decisions.

12.3

Ground the response in controlled evidence

Retrieval-augmented generation searches an approved collection and supplies relevant passages to the model. It can improve currency and traceability without retraining the model. The system still depends on collection completeness, document permissions, metadata, retrieval quality, and the model’s use of passages.

Retrieval should enforce access before content reaches the model. A user who cannot open a compensation file should not receive its content through an AI answer. Effective dates, jurisdictions, versions, and document types help restrict search to authoritative material.

Citations must be verified. A response may cite a relevant passage that does not support the particular claim, or combine several passages into an unsupported conclusion. Evaluation should test both retrieval recall and claim-to-source support.

12.4

Tools give the model a path to data and action

A model can be connected to tools that query databases, perform calculations, retrieve documents, or initiate workflows. Tool use can improve exactness, but it also expands risk. The model’s request should be validated by deterministic code, permissions should follow the user, and high-impact actions should require explicit approval.

Separate read from write. A system that summarizes receivables needs read access; it does not need authority to change customer status. If an action is useful, create a narrow tool with allowed parameters, validation, logging, and confirmation rather than giving broad system access.

Treat tool outputs as evidence with provenance. Record the query, parameters, source, run time, returned identifiers, and any transformations. A model’s narrative should not obscure the controlled calculation or transaction underneath.

12.5

Workflows and agents make different control choices

An AI workflow follows a substantially predetermined sequence: retrieve the policy, extract fields, calculate an amount, draft a memo, and route it for review. An agent receives an objective and dynamically decides which steps or tools to use based on intermediate results. Both may use language models and tools, but the agent has more discretion over the path.

Dynamic planning can help when the number and order of steps cannot be known in advance. An agent investigating an account variance might query the ledger, inspect supporting invoices, compare prior periods, and request another document only when evidence conflicts. The same flexibility enlarges the space of possible actions, errors, costs, and attacks. Use the least autonomy that the task genuinely requires.

Autonomy is not one switch. Designers choose what the system may read, which tools it may call, how many steps it may take, how much it may spend, which conditions require approval, and what it may change. A read-only research agent with a ten-step limit is a different risk from an agent that can email vendors and edit master data.

12.6

Identity, authority, and tool protocols

By 2026, agent identity and authority have become a central standards question. A system should distinguish the human user, the software agent acting for that user, the service being called, and the accountable organization. Authentication answers who or what is present. Authorization answers what that identity may do in this context. Delegation should be narrow, time-bounded where possible, and visible in logs.

Open connection protocols can standardize how AI applications discover and call tools or retrieve context. The Model Context Protocol is one current example. Standardization can reduce custom integration work, but a successful connection is not proof that the tool is appropriate, the data are authorized, or the result is correct. The host application still must enforce permissions, validate parameters, manage secrets, and record material actions.

Non-repudiation and provenance matter when an agent changes external state. A useful trace identifies the initiating user, agent and application version, delegated authority, tool and parameters, returned result, approval, final action, and timestamp. Logging sensitive data without limits creates a separate privacy and security problem, so logs need classification, access, retention, and integrity controls.

Source figure · AI actors across the lifecycle

An AI system distributes work across many actors and control boundaries

12.7

Long-running work needs budgets, checkpoints, and stop conditions

Some agentic tasks continue across many tool calls or wait for external events. A long-running investigation might collect documents, run analyses, pause for an employee response, and resume later. Background execution changes the control environment because the initiating user is no longer watching each step and the world may change between steps.

Define budgets for time, tokens, tool calls, data volume, and money. Use checkpoints before the system expands scope or performs a high-impact action. Make operations idempotent where possible so a retry does not create a duplicate journal entry, payment, or message. Store state in a controlled application rather than relying on a model's conversational memory.

Stop conditions are business rules, not merely technical timeouts. Stop when required evidence is missing, permissions change, contradictory amounts cannot be reconciled, an action exceeds materiality, a source attempts to redirect instructions, or a reviewer is required. The safest successful outcome may be a documented handoff rather than a completed automated task.

• Budget: maximum time, cost, steps, and data access.
• Checkpoint: a recoverable saved state with sufficient provenance.
• Approval gate: a point where a qualified person must authorize continuation or action.
• Idempotence: retrying an operation does not create a second unintended effect.
• Stop condition: a defined event that ends automation and triggers fallback or escalation.

12.8

Evaluate the task, not the demo

A compelling demonstration shows possibility, not reliability. Evaluation uses representative cases, difficult edge cases, known failures, and unacceptable outcomes. Test factual support, completeness, instruction following, citation quality, formatting, safety, consistency, latency, and cost as relevant.

Create a test set independent of prompt development where possible. If developers repeatedly tune against the same examples, performance on those examples becomes optimistic. Qualified subject-matter reviewers should define rubrics and inspect disagreements, not only assign one overall score.

Generative outputs allow many acceptable phrasings, so evaluation may combine deterministic checks, model-assisted grading, and human review. Automated grading itself must be validated. A system should not grade its own work without independent evidence.

12.9

Human oversight must be consequential

A human in the loop is meaningful only when the reviewer has time, competence, evidence, authority, and incentives to challenge the system. A required click on hundreds of persuasive outputs can become automation bias rather than oversight.

Design the interface to support disagreement. Show sources and uncertainties, not only a polished answer. Require reasons for overrides where appropriate, but do not make correction burdensome. Feed reviewed outcomes into monitoring without assuming every human decision is correct.

Assign final accountability clearly. If a tax manager approves an AI-assisted memo, the organization should know what the manager is expected to verify and what controls support that verification. Responsibility cannot be delegated to the model.

13.1

Find value at the task level

Occupations contain bundles of tasks. Some tasks involve language transformation, search, comparison, drafting, or classification and may be well suited to AI assistance. Others depend on physical observation, negotiation, accountable judgment, confidential relationships, or exact controlled execution. Evaluating the whole job as automatable or not automatable hides this variation.

Value can come from time saved, broader coverage, improved consistency, faster access to evidence, or new services. Claims should be compared with a baseline. Saving ten minutes on drafting may not create value if review takes twenty additional minutes or error risk increases.

Workflow redesign matters more than inserting a chat box. The organization may need better documents, metadata, approval paths, escalation, and measurement. AI can expose weaknesses in the existing information system rather than solve them.

13.2

The governance landscape

AI governance is moving from general principles toward operational expectations. NIST's generative-AI profile organizes risks and actions around the AI Risk Management Framework. NIST's 2026 work on deployed-system monitoring and agent standards emphasizes continuous observation, secure interoperability, identity, and authority. ISO/IEC 42001 frames AI governance as a management system, while ISO/IEC 42005 adds a structured approach to AI system impact assessment.

Accounting and audit guidance is also becoming more concrete. PCAOB staff outreach reported that firms were initially focused on administrative and research uses while exploring audit-planning and performance applications, with continuing concern about supervision, privacy, and security. COSO's 2026 generative-AI guidance connects new uses and risks—such as prompt manipulation, model or data drift, configuration weaknesses, and cyber threats—to auditable internal-control principles.

The European Union AI Act illustrates phased legal implementation. It entered into force on August 1, 2024; rules on prohibited practices and AI literacy began applying on February 2, 2025; and obligations for general-purpose AI models began applying on August 2, 2025. Certain transparency obligations are scheduled to apply on August 2, 2026. Timelines and implementing details can change, so organizations should verify the Commission's current guidance and obtain qualified legal advice for an actual use case.

The durable lesson is not to memorize one dated list. Accountants should maintain an inventory, classify uses by significance and jurisdiction, assign an owner for external requirements, translate those requirements into controls and evidence, and document the date and source used for the conclusion.

13.3

Map risks to the actual system

AI risks include unsupported output, incomplete retrieval, sensitive-data exposure, prompt injection, unauthorized action, discrimination, intellectual-property concerns, weak recordkeeping, vendor dependency, and performance drift. The significance depends on use. A brainstorming assistant and a system recommending payment holds require different controls.

Distinguish the model provider, application developer, deploying organization, user, data owner, reviewer, and affected party. Responsibilities can otherwise disappear between contracts and teams. A vendor may secure its platform while the customer configures excessive access or uses output for an untested purpose.

Risk assessment should include reasonably foreseeable misuse. Users may paste confidential records, rely on answers outside approved scope, or automate a manual workaround. Training and policy help, but technical restrictions and monitoring are often needed for high-risk behaviors.

Source figure · AI system lifecycle and dimensions

AI risk follows the system from planning through use and impact

13.4

Govern the full lifecycle

Governance begins before development. The proposal should define purpose, users, affected parties, data, decision significance, expected value, prohibited uses, and accountable owner. Higher-risk uses require stronger evidence and approval before resources are committed.

Development governance covers authorized data, documentation, testing, security, model and prompt versions, and acceptance criteria. Deployment governance covers access, training, workflow integration, human review, incident response, and fallback. Monitoring covers performance, usage, overrides, complaints, changes, and emerging risks. Retirement covers records, dependencies, replacement, and access removal.

An inventory of AI systems and material uses is foundational. The organization cannot govern systems it does not know exist. The inventory should distinguish experimentation from production and identify embedded AI features in ordinary software.

Source figure · NIST AI RMF Core

AI risk management combines governance with map, measure, and manage

13.5

Monitor the deployed decision system

Pre-deployment evaluation cannot recreate every production condition. Actual users ask new questions, source documents change, permissions evolve, integrations fail, attackers adapt, and providers update models. NIST's March 2026 report on monitoring deployed AI systems emphasizes that observation after launch is necessary because important failures emerge only in operation.

Monitoring should connect technical signals to business outcomes. Track retrieval failures, unsupported claims, tool errors, access denials, latency, cost, overrides, reviewer disagreement, complaints, affected-group outcomes, and downstream corrections as appropriate. A low technical error rate can still hide a material accounting failure if the errors concentrate in large or unusual transactions.

Define triggers before launch. A trigger may require investigation, temporary restriction, re-evaluation, reapproval, vendor notice, affected-party notice, rollback, or retirement. An incident process should preserve evidence, contain harm, identify root causes across people and systems, correct records, and feed lessons into controls and training.

13.6

Assurance follows claims, evidence, and control boundaries

An assurance engagement begins with the claim and criteria. 'Our company uses responsible AI' is too vague to test. A more testable assertion might state that all production AI uses affecting vendor payments are inventoried, risk-assessed, restricted from direct posting, evaluated before release, and monitored under specified policy during a stated period.

The practitioner should understand the full boundary: provider model, application, data and retrieval, connected tools, user permissions, manual review, monitoring, and downstream systems. Evidence may include inventory records, contracts, configuration exports, evaluation cases, access logs, traces, approvals, incident tickets, override analyses, and reperformance. Management representation alone is weak evidence when system-generated evidence is available.

AI can also affect the reliability of audit evidence itself. A generated summary may help a reviewer navigate a contract population, but the source contracts remain the evidence and the extraction process must be evaluated. If an agent collected or transformed evidence, the auditor considers completeness, accuracy, authorization, lineage, and whether the agent's actions altered the source environment.

• Define the assertion, criteria, period, population, and system boundary.
• Identify which controls are performed by the provider, customer, application, and reviewer.
• Prefer direct, system-generated, and reperformed evidence over polished narrative.
• Test exceptions and changes, not only normal demonstrations.
• Report limitations when evidence, criteria, or responsibility is unclear.

13.7

Fairness, explainability, and affected people

A system can create unequal consequences through data, labels, features, thresholds, workflow, or human response. Equal overall accuracy does not ensure equal error patterns. The relevant fairness question depends on context, rights, and harm, and may not be reducible to one metric.

Explainability should serve a purpose. Developers may need feature behavior and failure analysis. Reviewers may need evidence and reasons. Affected individuals may need understandable notice and a way to challenge an outcome. A complex explanation that no recipient can use is not effective transparency.

Governance includes appeal and correction. If an employee expense is flagged or a customer receives a credit decision, the process should define how errors are corrected and how repeated failures are identified. Human involvement does not automatically cure systematic bias.

13.8

Law and policy are changing control requirements

AI-related obligations can arise from privacy, employment, consumer protection, discrimination, intellectual property, records, sector regulation, contracts, and professional standards. Requirements vary by jurisdiction and use and continue to change. This book therefore treats legal status as a monitored control requirement rather than a fixed checklist.

The organization should identify applicable obligations with qualified legal and compliance professionals, translate them into system and process requirements, assign owners, and monitor changes. Contracts should address data use, confidentiality, security, incident notice, intellectual property, audit rights, service changes, and exit.

Recordkeeping deserves early design. If a consequential decision uses AI, the organization may need to preserve the inputs, relevant source version, system version, output, human review, final action, and notice. Reconstructing this evidence later may be impossible if the system was designed as an ephemeral conversation.

13.9

Accounting work will be redesigned

AI can reduce time spent searching, formatting, drafting, and performing routine comparisons. This may increase the importance of process understanding, data judgment, control design, verification, communication, and accountability. Entry-level work may change significantly because many traditional learning tasks are also automation candidates.

Organizations should preserve pathways for developing expertise. If junior staff no longer prepare the first draft or perform routine reconciliations, they still need opportunities to inspect evidence, understand exceptions, receive feedback, and build professional skepticism. Efficiency without learning can weaken the future review layer.

Accountants should learn to collaborate with systems without surrendering responsibility. Valuable skills include framing questions, evaluating sources, understanding data lineage, designing controls, interpreting uncertainty, recognizing when to escalate, and explaining conclusions to affected people.

14.1

Start with the organization and decision

A credible proposal names the organization or organizational type, user, decision, current process, pain point, and consequence. “Use AI in audit” is a technology theme. “Help internal-audit staff identify purchasing-policy exceptions before quarterly review so investigations begin while evidence is current” is a business problem.

Gather evidence about the current state: process documents, volumes, cycle times, error rates, interviews, system constraints, existing controls, and examples of exceptions. Avoid designing from anecdotes alone. The current process may contain compensating knowledge that is not visible in formal documentation.

Define scope and non-goals. A pilot that drafts exception summaries may be feasible; a project that autonomously investigates fraud, determines intent, and disciplines employees is not the same use. Narrow scope improves evaluation and accountability.

14.2

Map the current process and evidence

Show the process from trigger to decision and follow-up. Identify actors, systems, inputs, outputs, handoffs, delays, exceptions, and approvals. Connect each important decision to evidence. A map that omits spreadsheets, email, or manual workarounds will misrepresent how the process actually operates.

Separate symptoms from causes. Long close time may reflect late operational data, unclear ownership, repeated reconciliations, poor system integration, or excessive review. Automating one spreadsheet may shift the delay rather than remove it.

Document the baseline using measures the organization can continue to collect. Useful measures might include cycle time, backlog, error rate, coverage, rework, reviewer agreement, prevented loss, and user satisfaction. A pilot cannot demonstrate improvement without a comparison.

14.3

Design the future workflow

Describe which component performs each step: source system, database query, deterministic rule, retrieval service, model, reviewer, approver, or records repository. Identify where data enter, how permissions are enforced, what happens when evidence is missing, and which actions are prohibited.

Keep generative components away from tasks that require exact deterministic execution unless their output is validated. A model may draft an explanation of a variance; a controlled calculation should compute the variance. A model may recommend a classification; authorized workflow should post the transaction.

Design exceptions and fallback before the happy path. What happens when the provider is unavailable, the source is outdated, the output is malformed, or the reviewer disagrees? A controlled system fails visibly and safely.

14.4

Build a risk-and-control argument

For each material failure mode, state cause, event, consequence, control, owner, timing, evidence, and response. Include operational, reporting, privacy, security, fairness, legal, vendor, and adoption risks as relevant. Do not use human review as a universal answer without defining what the human reviews.

Consider residual risk after controls. If the system can still omit relevant policy passages, the reviewer may need direct source access and the use may remain advisory. If an error could cause an irreversible payment, additional deterministic controls and authorization are necessary.

Controls affect value and cost. A proposal that requires five independent reviews for every low-risk draft may be safe but uneconomic. The design should be proportionate and explain why the residual risk is acceptable for the intended use.

14.5

Design a pilot that can fail honestly

A pilot should test the most important assumptions with representative work. Define the population, sample, comparison, duration, success thresholds, unacceptable outcomes, reviewer qualifications, and decision after the pilot. Include ordinary cases, difficult exceptions, and historical failures.

Measure both quality and workflow. A system may draft faster but require more correction. Track source support, completeness, calculation accuracy, review time, user agreement, override reasons, alert backlog, and affected-party consequences as appropriate.

Avoid success criteria that guarantee a positive story, such as users found the demo interesting. A good pilot can lead to deployment, redesign, narrower scope, or termination. Learning that a use is not ready is a valuable result.

Source figure · Plan–Do–Check–Act

A pilot should turn evidence into the next controlled decision

14.6

Make the recommendation decision-ready

Executives need the problem, evidence, proposed change, expected value, material risks, control design, resource requirement, implementation sequence, and decision requested. Technical detail belongs where it supports confidence, not where it replaces the argument.

Quantify assumptions and show sensitivity. If expected savings depend on 60% adoption or a 30% reduction in review time, show what happens under lower performance. Identify ongoing costs for data maintenance, evaluation, training, provider services, control operation, and incident response.

State ownership. The proposal should name who owns the business outcome, data, system, controls, monitoring, and final decisions. A promising demonstration without operational ownership is not an implementation plan.