Applied AI library

Accounting Policy Assistant

Find the relevant accounting policy and prepare a review-ready treatment with paragraph-level citations.

At a glance

Translating from contract terms to accounting treatment can be challenging, especially when the contracts have special features. An analyst must identify the relevant policy documents, find the right paragraphs, and prepare a proposal. An accounting policy specialist repeats much of the same search before making or approving a decision.

The Accounting Policy Assistant agent prepares this work for review. It searches only an approved policy corpus, classifies how well that corpus supports an answer, and returns a cited proposal. It does not set new policies or approve an accounting treatment.

  1. Person: Curate the approved policy documents and source versions.
  2. Person: Raise the accounting question and provide the contract facts.
  3. Agent: Search the approved policies for relevant guidance.
  4. Agent: Draft a cited response or identify a policy gap.
  5. Code: Validate the response structure and citations.
  6. Person: Review the proposed treatment and make the decision.
Primary user
Finance analyst or accountant
When to use
A contract raises a policy question
Inputs
Contract facts, question, approved policies
Outputs
Cited treatment, alternatives, or policy gap

Preview the workflow steps

Follow a contract combining retroactive and prospective cover through policy search, drafting, validation, and specialist review. Select a step to inspect its example.

Person

Select the approved policy documents

The policy owner maintains the approved corpus and its version metadata. The assistant uses these documents as its source of accounting guidance.

Policy Document - POL-05 v1.4.pdf

Group Accounting Policy | POL-05

Premium Allocation Approach:
Eligibility and Mechanics

Version 1.4 | Effective 1 January 2025

Eligibility

§4.A group is eligible for the PAA if, and only if, at least one of the two conditions in IFRS 17.53 is met at initial recognition [IFRS 17.53].

§6.Where the coverage period of each contract in the group is one year or less, the group is automatically eligible for the PAA under IFRS 17.53(b), and no assessment of the difference between the PAA and the GMM is required [IFRS 17.53(b)].

Initial measurement

§11.On initial recognition of a group, the Group measures the liability for remaining coverage at the amount of the premiums received at initial recognition, minus any insurance acquisition cash flows at that date (subject to the expensing choice in §13), plus or minus any amount arising from the derecognition at that date of any asset or liability recognised for insurance acquisition cash flows and any other asset or liability previously recognised for cash flows related to the group [IFRS 17.55(a), 55(b)].

Subsequent measurement

§12.Subsequently, the carrying amount of the liability for remaining coverage at the end of each reporting period is the carrying amount at the start of the period, plus premiums received in the period, minus insurance acquisition cash flows (subject to §13), plus any amounts relating to the amortisation of insurance acquisition cash flows recognised as an expense in the period (subject to §13), plus any adjustment to a financing component (subject to §15), minus the amount recognised as insurance revenue for services provided in the period, and minus any investment component paid or transferred to the liability for incurred claims [IFRS 17.55(b)].

§16.For each period in which a group of contracts is measured under the PAA, the Group recognises insurance revenue as the amount of expected premium receipts (excluding any investment component and adjusted, where §15 applies, to reflect the time value of money) allocated to that period [IFRS 17.B126].

POL-05 | Version 1.4

Step-by-step guide

The chapters below explain how to get to the result above by building an agentic workflow. Each chapter includes the desired outcome and the steps to get there.

Back to overview

CHAPTER 1

Define task

Outcome

You have a clearly defined task, with a business purpose, explicit scope, and measurable success criteria.

Why it matters

Accounting decisions need clear reasoning and support from current policies. Defining the task first makes clear which decisions the accounting policy workflow should support and what is out of scope.

What to do

  1. 1Set the objectiveDescribe the purpose, intended audience, and scope of the accounting policy decision.
  2. 2Map current processMap how questions are received, policy documents are searched, and accounting treatments are drafted, reviewed, and approved. Identify who handles what and how the steps are connected.
  3. 3Define the scopeThe agentic workflow retrieves policy documents, classifies questions, and drafts accounting treatments. Interpretation and sign-off remain with policy specialists. Posting bookings is outside the scope.
  4. 4Set acceptance criteriaDefine what a good result looks like at each step. Require correct classification, current policy sources, traceable citations, and clear escalation where the policy is ambiguous or does not cover the question.
  5. 5Choose a test caseUse an accounting question and approved policy documents that a policy specialist can check against an expected classification and accounting treatment.

Example

A user asks about the accounting treatment of a standard twelve-month property quota-share treaty. The question gets classified as Defined since there are existing policy documents for it. The task then is to find the current premium-allocation policy, prepare the accounting treatment with citations, and send it to the policy specialist for sign-off.

CHAPTER 2

Prepare inputs

Outcome

You have a sample set of real input data, ready to use when building and testing the workflow.

Why it matters

Representative inputs give you a practical basis for building and testing the workflow. Current policies provide the authoritative basis for an answer, while past decision records provide examples for testing.

What to do

  1. 1Define sources and ownersName the owner of the policy documents, supporting documents, and past decision records.
  2. 2Prepare the dataKeep current and superseded policies distinguishable, and define how drafts are handled. Summarize each document's scope and create an index for retrieval.
  3. 3Assign reference IDsGive each policy document, section, and decision record a stable ID, such as POL-05 §16 for a policy paragraph. Link these references to the document's metadata so citations identify the correct source and version.
  4. 4Add input checksCheck that all relevant policy topics are covered by the input documents, with complete source references and clearly identified versions.

Example

The corpus contains POL-04 v2.1 as superseded and POL-04 v3.0 as the current version. A question about the risk adjustment must use v3.0 and state that v2.1 was found but not relied on. Removing the old paper makes retrieval simpler, but it would make comparisons across versions much harder down the road (e.g. What is the impact of the policy change?).

Policy document corpus

List of all policy documents and their metadata.

corpus/28 files
  • Additional policy documents
POL-04 v2.1
Document ID
POL-04
Status
Superseded
Title
Risk adjustment policy
Version
v2.1
Effective
2023-01-01
Owner
Group Accounting Policy
Scope summary
Measurement guidance and policy requirements for risk-adjustment determination, measurement, and presentation

CHAPTER 3

Design workflow

Outcome

You have a blueprint for building the workflow, from inputs to final output.

Why it matters

Designing the workflow before building it makes the processing steps and their connections explicit. For accounting policy, this clarifies how a question and relevant policy documents become a proposed treatment with citations.

What to do

  1. 1Break down the taskWork backwards from the desired output and identify the processing steps required to get there. Group activities that together produce one meaningful, intermediate result. For example, a set of relevant policy passages provides the basis for classifying the question and drafting a response.
  2. 2Specify each stepDescribe what each step receives, what it should do, and what it passes on. For instance, specify how retrieved policies inform the classification and how cited findings become a proposed accounting treatment.
  3. 3Define exception handlingSpecify when to request missing facts or refer a question to a policy specialist. Define how to present conflicting interpretations or a policy gap when a treatment cannot be proposed.
  4. 4Define the outputDefine the output schema, including field names, data types, and required values. Specify how missing information is represented and provide a populated example. For the policy response, include fields for the question classification, proposed treatment, and policy citations.

Example

The workflow separates finding relevant policies from assessing the question and drafting a response. This lets you check the relevance of the retrieved passages and the reasoning behind the proposed treatment independently. The drafting step then brings those results together in a response with citations.

Accounting policy workflow

  1. Person: Curate the approved policy documents and source versions.
  2. Person: Raise the accounting question and provide the contract facts.
  3. Agent: Search the approved policies for relevant guidance.
  4. Agent: Draft a cited response or identify a policy gap.
  5. Code: Validate the response structure and citations.
  6. Person: Review the proposed treatment and make the decision.

Selected stage

Curate policy docs

Input

Policy documents and version metadata

Output

Approved policy corpus

The final output could follow a schema like this:

Accounting policy output schema

{
  "classification": "defined | ambiguous | undefined",
  "proposed_treatment": "string or null",
  "evidence": [{"reference": "POL-05 §16", "source": "source link"}],
  "supported_interpretations": [],
  "escalation_summary": "string or null",
  "source_status_notice": "string or null",
  "review_status": "pending"
}

CHAPTER 4

Build AI workflow

Outcome

You have a working first version that follows the blueprint and produces the expected output.

Why it matters

A working first version gives you something concrete to improve. Building a first version reveals whether the proposed steps can work together on actual accounting questions and policy documents.

What to do

  1. 1Assign each stepDecide whether code, an AI agent, or a person should carry out each step. Use code to retrieve documents by reference, agents to interpret policy passages, and a policy specialist to approve the treatment.
  2. 2Implement each stepWrite the code and agent instructions required to process the step. You can use AI to assist you with this work. For the drafting step, supply the question, selected policy passages, and classification rules.
  3. 3Connect the stepsPass each step's output to the steps that depend on it. Implement the exception handling and requests for human input. Carry the stable IDs throughout each step all the way into the accounting policy response.
  4. 4Run the workflowProcess the sample inputs from start to finish. Inspect intermediate results and fix failures until the workflow produces an output that follows the schema.

Example

Implement retrieval so the drafting agent receives the selected policy passages with their reference IDs. This gives it the relevant context and the references needed for citations. Run the sample question through the connected steps to produce a first structured response for specialist review.

Accounting policy workflow

  1. Person: Curate the approved policy documents and source versions.
  2. Person: Raise the accounting question and provide the contract facts.
  3. Agent: Search the approved policies for relevant guidance.
  4. Agent: Draft a cited response or identify a policy gap.
  5. Code: Validate the response structure and citations.
  6. Person: Review the proposed treatment and make the decision.

Selected stage

Curate policy docs

Person

Input

Policy documents and version metadata

Output

Approved policy corpus

CHAPTER 5

Add controls

Outcome

You have checks in place that catch invalid results and raise them for review.

Why it matters

Controls reduce the risk of users acting on incorrect results. They also give reviewers the evidence needed to investigate an issue without retracing the entire workflow.

What to do

  1. 1Identify possible failuresWalk through the existing workflow steps and identify errors that could compromise the final output. For accounting policy, consider incorrect policy versions, unresolved citations, and treatments that lack support.
  2. 2Implement validationsImplement checks for those errors. The checks can be performed by code or agents. For instance, check required response fields and allowed classification values in code and use an agent to assess whether the cited passages support the treatment.
  3. 3Raise issues for reviewFlag failed checks alongside the results and summarize them for the reviewer. Explain what failed, include the relevant evidence, and state what needs checking or correcting. For example, highlight an unresolved citation and include the proposed treatment.

Example

A proposed accounting treatment cites a policy paragraph that cannot be found. The citation check flags the reference alongside the treatment and adds the issue to the review summary. The specialist receives the response with the unresolved reference clearly identified for correction.

Control ownership

Assign each check to code, a model, or a person.

All required corpus and section metadata is present

Code

The source status and effective date are valid

Code

The selected policy documents and sections are relevant to the question

Model

The Defined, Ambiguous, or Undefined classification is supported by the policies

Model

The output contains all required fields and only allowed values

Code

The proposed accounting treatment is correct and can be approved

Person

CHAPTER 6

Build evaluation set

Outcome

You have a set of test cases and scoring criteria to systematically measure workflow quality and reveal where improvements are needed.

Why it matters

A successful run does not show how the workflow handles difficult cases. Evaluations give you a consistent basis for comparing versions and detecting when a change makes results better or worse.

What to do

  1. 1Collect representative casesGather realistic inputs covering common tasks, difficult cases, and known failures. Include cases where the workflow should identify missing information or raise an issue for review. Include questions with clear policy coverage, conflicting interpretations, and policy gaps.
  2. 2Define expected resultsSpecify the expected results for each case before running the evaluation.
  3. 3Set up gradingDefine how each result will be assessed against those expectations. Use code for exact comparisons and an agent or person with clear scoring criteria for judgments about content quality.
  4. 4Run and compareRun the evaluation set and inspect failures to identify which steps need improvement. Record a baseline and repeat the evaluation after changes to compare performance.

Example

An evaluation case asks about a treatment the policy documents do not cover. The expected response is Undefined, with no proposed treatment and a request for specialist review.

Evaluation results

Test cases

3

Pass rate

67%

Latency

2.4s

Cost per task

$0.34

Test caseExpectedPassed
DefinedPassed
Input
How should a one-year property quota-share contract be treated under the supplied accounting policies?
AmbiguousFailed
UndefinedPassed

CHAPTER 7

Design for everyday use

Outcome

You have an operating model that defines who reviews the results, supported by a user interface for everyday operations.

Why it matters

A user interface brings the results, supporting evidence, and review actions together for everyday use. The reviewer must be able to challenge the workflow outputs without having to redo all the work.

What to do

  1. 1Assign responsibilitiesDefine who uses the workflow, who reviews and approves results, and who maintains it.
  2. 2Design the user interfaceGive users a clear way to provide inputs and inspect results.
  3. 3Define the review processSpecify when review is required, what the reviewer must check, and how corrections and approvals are recorded.
  4. 4Create audit logRecord the inputs, workflow version, outputs, and review decisions so each result can be traced back to how it was produced and approved.
  5. 5Prepare for ongoing operationsDefine how the workflow will be monitored, maintained, and improved over time.

Example

A reviewer opens the proposed accounting treatment and checks the cited policy passages. They approve the treatment, make corrections, or request further information through the same interface. The audit log records their actions and final decision.

Accounting policy report

Property quota-share treaty

Reviewer action items

Proposed accounting treatment

Defined

Sources

POL-05 §4, §6POL-05 §11POL-05 §12, §16

Production-readiness checklist

Before releasing the Accounting Policy Assistant to production, the following additional steps are required:

Performance Efficiency

3 items

Reliability

3 items

Security

2 items

Cost Control

3 items

Operational Excellence

4 items

End of this guide

Return to the overview, or explore the other guides in the Applied AI library.