Governed rebate & revenue close (ASC 606/705/842): explain, ingest, compute, trace to source.
Maintain this server? Claim it
Call this server's tools from your browser. Nothing to install.
Requests go through mcptry because browsers can't call most MCP servers directly. Header values are sent to the server for that request only and are never stored or logged.
Tool list from our last check. Connect live to refresh it.
Build a GOVERNED analytics report over the rebate data. Pick a MEASURE and GROUP it BY a dimension — the report is composed from a fixed semantic layer (no raw SQL), so it's deterministic, read-only, and ties to the ledger (accrued uses the SAME earned formula as the money path). measure: 'accrued' (earned rebate), 'settled' (paid), 'basis' (transaction amount), or 'count' (events). group_by: 'agreement', 'class' (a declared dimension — pass dimension_key, e.g. interchange_class), 'month', or 'quarter'. Optionally restrict to one agreement_id. Returns the grouped rows + total. Use this when the user asks to see/analyze/break down their rebates (e.g. 'rebate accrued by interchange class', 'settled by month'). Requires a connected Aurgus account.
What to measure: accrued (earned) | settled (paid) | basis (transaction amount) | count (events).
How to break it down: agreement | class (needs dimension_key) | month | quarter.
Optional — restrict the report to one agreement.
Required when group_by='class': the declared dimension to group by, e.g. 'interchange_class'.
Pick your client. Values in capitals, like YOUR_TOKEN, are yours to fill in.
claude mcp add --transport http aurgus https://mcp.aurgus.com/api/mcp
Build a GOVERNED analytics report over the rebate data. Pick a MEASURE and GROUP it BY a dimension — the report is composed from a fixed semantic layer (no raw SQL), so it's deterministic, read-only, and ties to the ledger (accrued uses the SAME earned formula as the money path). measure: 'accrued' (earned rebate), 'settled' (paid), 'basis' (transaction amount), or 'count' (events). group_by: 'agreement', 'class' (a declared dimension — pass dimension_key, e.g. interchange_class), 'month', or 'quarter'. Optionally restrict to one agreement_id. Returns the grouped rows + total. Use this when the user asks to see/analyze/break down their rebates (e.g. 'rebate accrued by interchange class', 'settled by month'). Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| measure* | string | What to measure: accrued (earned) | settled (paid) | basis (transaction amount) | count (events). |
| group_by* | string | How to break it down: agreement | class (needs dimension_key) | month | quarter. |
| agreement_id | string | Optional — restrict the report to one agreement. |
| dimension_key | string | Required when group_by='class': the declared dimension to group by, e.g. 'interchange_class'. |
{
"type": "object",
"required": [
"measure",
"group_by"
],
"properties": {
"measure": {
"enum": [
"accrued",
"settled",
"basis",
"count"
],
"type": "string",
"description": "What to measure: accrued (earned) | settled (paid) | basis (transaction amount) | count (events)."
},
"group_by": {
"enum": [
"agreement",
"class",
"month",
"quarter"
],
"type": "string",
"description": "How to break it down: agreement | class (needs dimension_key) | month | quarter."
},
"agreement_id": {
"type": "string",
"description": "Optional — restrict the report to one agreement."
},
"dimension_key": {
"type": "string",
"description": "Required when group_by='class': the declared dimension to group by, e.g. 'interchange_class'."
}
},
"additionalProperties": false
}THE one way to talk to Aurgus — the client's revenue-management controller. For ANYTHING the user says to Aurgus (a greeting, 'close Q3', 'where are we', 'what do you need from me'), call THIS with their message rather than picking a specific tool; Aurgus reads the engagement's real state, leads like a firm, and tells you the single next step. Pass entity/period/program when the user has named them (so Aurgus can open the engagement), and engagement_id once one is open. The specialized tools (ingest, compute_close, sign_close, …) are the controller's hands — reach for one only when Aurgus's reply tells you to (e.g. to ingest a CSV, compute with numbers, or sign). Free to greet; a real run on the user's data needs a connected account.
| Argument | Type | Description |
|---|---|---|
| entity | string | The client entity, when the user has named who they're closing for. |
| period | string | The close period, when named (e.g. 'Q3 2026'). |
| message | string | What the user said to Aurgus, verbatim. |
| program | string | The program being closed, when named (e.g. 'tiered volume rebate'). |
| direction | string | Which side the client is on for a billback / chargeback / rebate: 'paying' (sell-side → ASC 606, reduces revenue) or 'receiving' (buy-side → ASC 705-20, reduces cost of sales). Pass it once the user says which; Aurgus asks rather than assumes. |
| engagement_id | string | The current engagement, once one is open. |
| who_certifies | string | Who will certify the terms + mapping (name or email), when the user has named them — captured at open so the certifier is on the engagement from the start. |
{
"type": "object",
"properties": {
"entity": {
"type": "string",
"description": "The client entity, when the user has named who they're closing for."
},
"period": {
"type": "string",
"description": "The close period, when named (e.g. 'Q3 2026')."
},
"message": {
"type": "string",
"description": "What the user said to Aurgus, verbatim."
},
"program": {
"type": "string",
"description": "The program being closed, when named (e.g. 'tiered volume rebate')."
},
"direction": {
"type": "string",
"description": "Which side the client is on for a billback / chargeback / rebate: 'paying' (sell-side → ASC 606, reduces revenue) or 'receiving' (buy-side → ASC 705-20, reduces cost of sales). Pass it once the user says which; Aurgus asks rather than assumes."
},
"engagement_id": {
"type": "string",
"description": "The current engagement, once one is open."
},
"who_certifies": {
"type": "string",
"description": "Who will certify the terms + mapping (name or email), when the user has named them — captured at open so the certifier is on the engagement from the start."
}
},
"additionalProperties": false
}Call this the moment the user greets Aurgus or wants to start — 'Aurgus, hi', 'hello', 'hey Aurgus', 'let's start', 'I want to run a close', 'where do I begin'. Aurgus introduces itself as the client's independent revenue-management controller and LEADS into the engagement, asking who the client is, the period, and what's being closed. Free, no account needed, computes nothing — the next step is open_engagement.
| Argument | Type | Description |
|---|---|---|
| scenario | string | Optional: what the user wants to close, if they said (woven into the greeting). |
{
"type": "object",
"properties": {
"scenario": {
"type": "string",
"description": "Optional: what the user wants to close, if they said (woven into the greeting)."
}
},
"additionalProperties": false
}Close an agreement for good — the terminal true-up at the END of its life (its term ended, or it's being wound down). Closing posts a final true-up Adjustment that matches the accrual to the settled amount (open → $0), THEN FREEZES the agreement: it moves to 'closed' and NO new transactions ever calculate against it again. This is NOT the periodic run (compute_close) or the periodic payout (settlement) — it ends the agreement. Because it MOVES MONEY (the true-up Adjustment), call WITHOUT confirm first to DRY-RUN — it reports the adjustment that would post and that the agreement will be frozen. Call again with confirm:true to post it and close. Terminal. Needs the agreement_id. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| force | boolean | Administrative close flag, recorded on the audit trail (the true-up always resolves the open balance regardless). |
| reason | string | Why it's being closed — recorded on the audit trail. |
| confirm | boolean | Omit/false to DRY-RUN (preview the terminal true-up + freeze); true to post the Adjustment and close. |
| agreement_id* | string | The agreement to close (terminal). |
{
"type": "object",
"required": [
"agreement_id"
],
"properties": {
"force": {
"type": "boolean",
"description": "Administrative close flag, recorded on the audit trail (the true-up always resolves the open balance regardless)."
},
"reason": {
"type": "string",
"description": "Why it's being closed — recorded on the audit trail."
},
"confirm": {
"type": "boolean",
"description": "Omit/false to DRY-RUN (preview the terminal true-up + freeze); true to post the Adjustment and close."
},
"agreement_id": {
"type": "string",
"description": "The agreement to close (terminal)."
}
},
"additionalProperties": false
}Build a rebate/incentive agreement by talking it through — no document needed. Describe the program in plain words and Aurgus DRAFTS the terms (who qualifies, how volume is measured and over what period, the threshold, the rate or per-unit reward, any cap, and approval routing) and asks the consultant-style questions a controller would ask before assuming. IMPORTANT: these terms are DRAFTED by the model from your words — they are PROPOSED, NOT PARSED, and nothing is created. When the terms are right, call again with finalize=true and the reviewed proposal, and Aurgus stages it for a person with approval authority to approve in the browser (you can NOT approve your own). This is how you establish an agreement (ASC 606 step 1) when you have no document — before any transaction data is asked for. When a document exists, prefer ingest_agreement (its deterministic parser touches the numbers with zero LLM).
| Argument | Type | Description |
|---|---|---|
| finalize | boolean | Set true ONLY after the terms have been reviewed and the follow-ups resolved. Stages the proposal for human approval; omit/false to just draft and refine. |
| proposal | object | Required when finalize=true: the EXACT drafted proposal returned by a prior (non-finalize) call, echoed back verbatim — so what is staged is exactly what was reviewed. Staging does NOT re-run the model. |
| description* | string | Plain-language description of the program — who it's for, how it's measured and over what period, the rate/threshold/cap, the dates. On the first turn, just describe it. |
| clarifications | array | Answers to the follow-up questions from a previous turn, so the draft refines. Each item pairs the question asked with the answer. |
{
"type": "object",
"required": [
"description"
],
"properties": {
"finalize": {
"type": "boolean",
"description": "Set true ONLY after the terms have been reviewed and the follow-ups resolved. Stages the proposal for human approval; omit/false to just draft and refine."
},
"proposal": {
"type": "object",
"required": [
"agreementName",
"primitives"
],
"properties": {
"direction": {
"type": [
"object",
"null"
]
},
"primitives": {
"type": "object"
},
"programType": {
"type": "string"
},
"customerName": {
"type": [
"string",
"null"
]
},
"agreementName": {
"type": "string"
}
},
"description": "Required when finalize=true: the EXACT drafted proposal returned by a prior (non-finalize) call, echoed back verbatim — so what is staged is exactly what was reviewed. Staging does NOT re-run the model."
},
"description": {
"type": "string",
"description": "Plain-language description of the program — who it's for, how it's measured and over what period, the rate/threshold/cap, the dates. On the first turn, just describe it."
},
"clarifications": {
"type": "array",
"items": {
"type": "object",
"required": [
"question",
"answer"
],
"properties": {
"answer": {
"type": "string"
},
"question": {
"type": "string"
}
},
"additionalProperties": false
},
"description": "Answers to the follow-up questions from a previous turn, so the draft refines. Each item pairs the question asked with the answer."
}
},
"additionalProperties": false
}The RUN step (step 6) of an open engagement — work the governed, deterministic earned → settled → open accrual across the engagement's active agreements and certified data. Do NOT call this as the first thing when a user says 'compute the close': a firm opens the engagement first (open_engagement), establishes the agreement, requests + certifies the data, and only then runs. If no engagement is open, this refuses and leads back to open_engagement. You get back the number, how earned / claimed / credited line up, and any flag worth raising. Nothing posts to the GL; the number is prepared for approval. Requires a connected Aurgus account.
No arguments.
{
"type": "object",
"properties": {},
"additionalProperties": false
}Compute a sales-commission engagement under ASC 340-40 (incremental cost to obtain a contract). Give the commission amount, the benefit period it amortizes over, and how many months have elapsed; it classifies the cost, then capitalizes a recoverable commission and amortizes it straight-line — returning the capitalized asset, amortization to date, the period expense, and the net carrying amount. This is a capitalized asset and an amortization schedule, NOT revenue. It refuses (asks) if recoverability or the amount is unclear. The result is recorded on the engagement file; a principal signs before the workpapers are delivered.
| Argument | Type | Description |
|---|---|---|
| engagement_id* | string | The commission engagement (opened via open_engagement, classified as a commission). |
| benefit_months* | number | The benefit period over which it amortizes, in months. |
| commission_usd* | number | The commission — the incremental cost to obtain the contract. |
| months_elapsed* | number | Months elapsed into the benefit period at this close. |
| contract_terminated | boolean | Set true if the underlying contract was TERMINATED early. The remaining capitalized asset can't simply finish amortizing — it triggers an ASC 340-40-35-3 impairment assessment, raised as an open item rather than closed clean. |
| expected_to_be_recovered | boolean | Whether the cost is expected to be recovered (340-40-25-1). Omit if unknown and it will ask. |
| elect_practical_expedient | boolean | Set true ONLY if the entity has ELECTED the ≤1-year practical expedient (340-40-25-4) to expense a commission that amortizes within a year. Omit/false → a ≤12-month commission CAPITALIZES (25-1); the expedient is a disclosed election, never auto-applied. |
| remaining_consideration_usd | number | On a terminated contract, the consideration the entity still expects to receive (340-40-35-3(a)). Omit if none/unknown and the full carrying amount is flagged for impairment review. |
{
"type": "object",
"required": [
"engagement_id",
"commission_usd",
"benefit_months",
"months_elapsed"
],
"properties": {
"engagement_id": {
"type": "string",
"description": "The commission engagement (opened via open_engagement, classified as a commission)."
},
"benefit_months": {
"type": "number",
"description": "The benefit period over which it amortizes, in months."
},
"commission_usd": {
"type": "number",
"description": "The commission — the incremental cost to obtain the contract."
},
"months_elapsed": {
"type": "number",
"description": "Months elapsed into the benefit period at this close."
},
"contract_terminated": {
"type": "boolean",
"description": "Set true if the underlying contract was TERMINATED early. The remaining capitalized asset can't simply finish amortizing — it triggers an ASC 340-40-35-3 impairment assessment, raised as an open item rather than closed clean."
},
"expected_to_be_recovered": {
"type": "boolean",
"description": "Whether the cost is expected to be recovered (340-40-25-1). Omit if unknown and it will ask."
},
"elect_practical_expedient": {
"type": "boolean",
"description": "Set true ONLY if the entity has ELECTED the ≤1-year practical expedient (340-40-25-4) to expense a commission that amortizes within a year. Omit/false → a ≤12-month commission CAPITALIZES (25-1); the expedient is a disclosed election, never auto-applied."
},
"remaining_consideration_usd": {
"type": "number",
"description": "On a terminated contract, the consideration the entity still expects to receive (340-40-35-3(a)). Omit if none/unknown and the full carrying amount is flagged for impairment review."
}
},
"additionalProperties": false
}Measure a lease under ASC 842 (v1: the lessee side — real estate and equipment). Give the term, the CERTIFIED discount rate (the rate implicit in the lease, or the incremental borrowing rate — it will NOT assume one), and the payment schedule; it measures the lease liability (present value of the payments), the right-of-use asset (liability + initial direct costs − incentives), and the amortization schedule — a single straight-line lease cost for an operating lease (842-20-25-6) or amortization + interest for a finance lease (842-20-25-5). Usage-based variable payments are excluded from the liability (842-10-30-6). Whatever it can't ground — a missing rate, an undetermined classification — it logs as an OPEN ITEM rather than guessing; lessor accounting is deferred. The result is recorded on the engagement file; a principal signs before the workpapers are delivered.
| Argument | Type | Description |
|---|---|---|
| party | string | v1 is lessee-only; a lessor request is deferred to v2. |
| payments* | array | The lease payment schedule. |
| prepaid_usd | number | Payments made at or before commencement — added to the ROU asset. |
| term_periods* | number | The lease term as a number of periods. |
| engagement_id* | string | The lease engagement (opened via open_engagement, classified as a lease). |
| classification | string | The certified classification. Omit to default to operating (the v1 real-estate wedge). |
| incentives_usd | number | Lease incentives received (e.g. a tenant-improvement allowance) — reduces the ROU asset. |
| payment_timing | string | Whether payments fall at period end (arrears, default) or start (advance). |
| periods_per_year | number | Periods per year: 12 monthly (default), 4 quarterly, 1 annual. |
| annual_discount_rate_pct* | number | The CERTIFIED annual discount rate (%). Omit and it will ask — it never assumes a rate. |
| initial_direct_costs_usd | number | Initial direct costs — added to the ROU asset. |
{
"type": "object",
"required": [
"engagement_id",
"term_periods",
"annual_discount_rate_pct",
"payments"
],
"properties": {
"party": {
"enum": [
"lessee",
"lessor"
],
"type": "string",
"description": "v1 is lessee-only; a lessor request is deferred to v2."
},
"payments": {
"type": "array",
"items": {
"type": "object",
"required": [
"period_index",
"amount_usd"
],
"properties": {
"kind": {
"enum": [
"fixed",
"in_substance_fixed",
"index_based",
"usage"
],
"type": "string",
"description": "Payment type. usage-based is excluded from the liability (842-10-30-6)."
},
"amount_usd": {
"type": "number",
"description": "The payment amount."
},
"period_index": {
"type": "number",
"description": "1-based period this payment falls in."
}
},
"additionalProperties": false
},
"description": "The lease payment schedule."
},
"prepaid_usd": {
"type": "number",
"description": "Payments made at or before commencement — added to the ROU asset."
},
"term_periods": {
"type": "number",
"description": "The lease term as a number of periods."
},
"engagement_id": {
"type": "string",
"description": "The lease engagement (opened via open_engagement, classified as a lease)."
},
"classification": {
"enum": [
"operating",
"finance"
],
"type": "string",
"description": "The certified classification. Omit to default to operating (the v1 real-estate wedge)."
},
"incentives_usd": {
"type": "number",
"description": "Lease incentives received (e.g. a tenant-improvement allowance) — reduces the ROU asset."
},
"payment_timing": {
"enum": [
"arrears",
"advance"
],
"type": "string",
"description": "Whether payments fall at period end (arrears, default) or start (advance)."
},
"periods_per_year": {
"type": "number",
"description": "Periods per year: 12 monthly (default), 4 quarterly, 1 annual."
},
"annual_discount_rate_pct": {
"type": "number",
"description": "The CERTIFIED annual discount rate (%). Omit and it will ask — it never assumes a rate."
},
"initial_direct_costs_usd": {
"type": "number",
"description": "Initial direct costs — added to the ROU asset."
}
},
"additionalProperties": false
}Run the full ASC 606 five-step recognition for a general revenue contract: identify the performance obligations (Step 2), allocate the transaction price by standalone selling price (Step 4), and recognize over time or at a point in time (Step 5). Give the transaction price and the promised items (each with its standalone selling price). Whatever the engine can't determine from what you provide — distinctness, timing — it logs as an OPEN ITEM rather than guessing. The result is recorded on the engagement file; a principal signs before the workpapers are delivered.
| Argument | Type | Description |
|---|---|---|
| items* | array | The promised items in the contract. |
| engagement_id* | string | The revenue-contract engagement (opened + classified as a general revenue contract). |
| transaction_price_usd* | number | The contract's transaction price. |
{
"type": "object",
"required": [
"engagement_id",
"transaction_price_usd",
"items"
],
"properties": {
"items": {
"type": "array",
"items": {
"type": "object",
"required": [
"id"
],
"properties": {
"id": {
"type": "string",
"description": "A short id for the promised item."
},
"label": {
"type": "string",
"description": "What the item is."
},
"ssp_usd": {
"type": "number",
"description": "The standalone selling price of this item, if known."
},
"ssp_method": {
"enum": [
"observable",
"adjusted_market",
"expected_cost_plus",
"residual"
],
"type": "string",
"description": "How the SSP was determined."
},
"separately_usable": {
"type": "boolean",
"description": "Can the customer benefit from it on its own? Omit if unknown and it becomes an open item."
}
},
"additionalProperties": false
},
"description": "The promised items in the contract."
},
"engagement_id": {
"type": "string",
"description": "The revenue-contract engagement (opened + classified as a general revenue contract)."
},
"transaction_price_usd": {
"type": "number",
"description": "The contract's transaction price."
}
},
"additionalProperties": false
}Split a trade-spend payment to a customer (co-op advertising, MDF, slotting, listing allowance) under ASC 606-10-32-26 / 705-20-25-2. If the payment buys a DISTINCT good or service the customer actually provides (e.g. advertising with proof-of-performance), it's a purchase/expense UP TO that good's fair value; any EXCESS over fair value reduces revenue. Give the payment amount, whether it buys a distinct good/service, and that good's fair value — it returns the expense leg and the revenue-reduction leg. It refuses (asks) for the fair value rather than guess; if it buys nothing distinct, the whole payment reduces revenue (no split). Nothing posts; a principal signs the close.
| Argument | Type | Description |
|---|---|---|
| payment_usd* | number | The trade-spend payment to the customer. |
| fair_value_usd | number | Fair value of that distinct good/service. Required to split; omit and it will ask. |
| buys_distinct_good_or_service | boolean | True if the customer transfers a distinct good/service (e.g. advertising with proof-of-performance). False → the whole payment reduces revenue (no split). |
{
"type": "object",
"required": [
"payment_usd"
],
"properties": {
"payment_usd": {
"type": "number",
"description": "The trade-spend payment to the customer."
},
"fair_value_usd": {
"type": "number",
"description": "Fair value of that distinct good/service. Required to split; omit and it will ask."
},
"buys_distinct_good_or_service": {
"type": "boolean",
"description": "True if the customer transfers a distinct good/service (e.g. advertising with proof-of-performance). False → the whole payment reduces revenue (no split)."
}
},
"additionalProperties": false
}Record the human's answer to a customer-grouping question Aurgus asked — a grouping compute_close PROPOSED ('GPG LLC resembles Global Procurement Group LLC', or 'these are the GPO's members'), OR a change to a roster Aurgus already knows ('did anything change?' → a new member joined, or one left). Aurgus never changes a group on its own — this tool is the person's approval, and what makes Aurgus remember. Added names become DATE-CONTROLLED members of the agreement's customer scope so the NEXT close matches them automatically; removing a member ENDS its membership as-of a date (never deletes — its past purchases stay attributed, only later ones stop rolling up). Use ONLY after Aurgus surfaced the question and the user answered; pass the agreement_id and the name(s) exactly as they appear in the data. Set valid_from/valid_to for a real join/leave date (a GPO join, an acquisition, a rename, a member leaving); omit valid_from for open-ended. After confirming, run compute_close again to fold the change in.
| Argument | Type | Description |
|---|---|---|
| members | array | Name(s) the user confirmed BELONG to this agreement (added as members), exactly as they appear in the data. |
| agreement_id* | string | The agreement whose customer scope this concerns — from the compute_close proposal or roster. |
| ended_members | array | Member(s) that LEFT the group — their membership is ended as-of valid_to (not deleted; prior purchases stay attributed). |
{
"type": "object",
"required": [
"agreement_id"
],
"properties": {
"members": {
"type": "array",
"items": {
"type": "object",
"required": [
"name"
],
"properties": {
"name": {
"type": "string",
"description": "The customer name to group, verbatim from the data (e.g. 'GPG LLC')."
},
"valid_to": {
"type": "string",
"description": "YYYY-MM-DD — when the membership ended, if already known. Omit for still-a-member."
},
"valid_from": {
"type": "string",
"description": "YYYY-MM-DD — when the membership began (GPO join / rename date). Omit for open-ended."
}
},
"additionalProperties": false
},
"description": "Name(s) the user confirmed BELONG to this agreement (added as members), exactly as they appear in the data."
},
"agreement_id": {
"type": "string",
"description": "The agreement whose customer scope this concerns — from the compute_close proposal or roster."
},
"ended_members": {
"type": "array",
"items": {
"type": "object",
"required": [
"name",
"valid_to"
],
"properties": {
"name": {
"type": "string",
"description": "The member that left, exactly as on file."
},
"valid_to": {
"type": "string",
"description": "YYYY-MM-DD — the date the membership ended (the last day they count as a member)."
}
},
"additionalProperties": false
},
"description": "Member(s) that LEFT the group — their membership is ended as-of valid_to (not deleted; prior purchases stay attributed)."
}
},
"additionalProperties": false
}Connect the client's ERP / POS / order system (or Zapier) to Aurgus by creating an API key for their account. This is how transactions flow IN automatically (no CSV uploads) and how Aurgus's journal entries flow OUT to their GL — through the Aurgus Open-API (/api/v1) that the key authenticates. The key carries DATA-INTAKE authorization ONLY: it can push transactions and read the journal/position, but it can NEVER run a close, settle, or move money — those stay human-gated in the workspace. Because a key is a real credential, call WITHOUT confirm first to explain what will be created and ask; the MOMENT the user says yes / 'create it' / 'go ahead', call again with confirm:true to actually create it — do NOT re-ask or re-confirm. NEVER ask the user for a label: it is optional, so omit it unless the user volunteered one in the same breath; they can rename the key later in Account. On creation the plaintext key is returned ONCE with the steps to finish in Zapier. The person can view or revoke keys anytime in Account → API keys. Use this when the user asks to connect their system, integrate their ERP/POS, or set up Zapier. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| label | string | Optional label. Set it ONLY if the user already named one (e.g. 'Zapier'); otherwise OMIT it and do not ask — never block key creation on a label. |
| confirm | boolean | Omit/false to EXPLAIN what will be created and ask; true to actually create the key and return it once. |
{
"type": "object",
"properties": {
"label": {
"type": "string",
"description": "Optional label. Set it ONLY if the user already named one (e.g. 'Zapier'); otherwise OMIT it and do not ask — never block key creation on a label."
},
"confirm": {
"type": "boolean",
"description": "Omit/false to EXPLAIN what will be created and ask; true to actually create the key and return it once."
}
},
"additionalProperties": false
}Retire a WRONG agreement that has already accrued — reverse its postings, then archive it. Voiding alone only stops FUTURE accruals; this UNWINDS what already accrued by appending a Reversal for every earning event (earned → $0, strictly append-only — the originals AND the reversals both stay on the ledger for audit), then voids the agreement. Call WITHOUT confirm first to DRY-RUN — it reports how many postings and how much $ will be reversed and warns if any was already settled (a clawback). Call again with confirm:true to apply. Refuses if the agreement is posted to the ERP (supersede it instead). Needs the agreement_id. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| confirm | boolean | Omit/false to DRY-RUN (preview the reversal); true to actually reverse the postings and archive the agreement. |
| agreement_id* | string | The agreement to reverse & defunct. |
{
"type": "object",
"required": [
"agreement_id"
],
"properties": {
"confirm": {
"type": "boolean",
"description": "Omit/false to DRY-RUN (preview the reversal); true to actually reverse the postings and archive the agreement."
},
"agreement_id": {
"type": "string",
"description": "The agreement to reverse & defunct."
}
},
"additionalProperties": false
}Change an agreement's TERMS — its name, the counterparty (customer_name), the direction (payable_sell_side = you pay a rebate / receivable_buy_side = you earn one), the validity window (valid_from / valid_to, YYYY-MM-DD; pass valid_to:null for open-ended), or the accrual / settlement cadence. Send only the fields to change. This runs the SAME governed core as the workspace edit form (one implementation): activating is blocked if the config isn't ASC-606-conformant; a cadence/validity value must satisfy the agreement type's contract; direction and type are posting-locked once a document hits the ERP; and because a validity change re-evaluates already-accrued periods, it does NOT post money through you — it raises a gated Recalculate card the operator approves in the workspace (nothing is backdated without approval). To CHANGE RATES use edit_agreement_rates; to change STATUS use the audited status flow. Needs the agreement_id. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| name | string | New agreement name. |
| valid_to | string | null | New validity end, YYYY-MM-DD, or null for open-ended. A validity change raises a gated Recalculate card. |
| direction | string | payable_sell_side (you pay the rebate) or receivable_buy_side (you earn it). Posting-locked once a document is posted to the ERP. |
| valid_from | string | New validity start, YYYY-MM-DD (bare calendar date). |
| agreement_id* | string | The agreement to edit. |
| customer_name | string | New counterparty / customer name. |
| accrual_cadence | string | How often to accrue: realtime | daily | weekly | monthly | per_event. |
| settlement_cadence | string | How often it settles: weekly | semi_monthly | monthly | quarterly | semi_annual | annual | threshold | ad_hoc. |
{
"type": "object",
"required": [
"agreement_id"
],
"properties": {
"name": {
"type": "string",
"description": "New agreement name."
},
"valid_to": {
"type": [
"string",
"null"
],
"description": "New validity end, YYYY-MM-DD, or null for open-ended. A validity change raises a gated Recalculate card."
},
"direction": {
"enum": [
"payable_sell_side",
"receivable_buy_side"
],
"type": "string",
"description": "payable_sell_side (you pay the rebate) or receivable_buy_side (you earn it). Posting-locked once a document is posted to the ERP."
},
"valid_from": {
"type": "string",
"description": "New validity start, YYYY-MM-DD (bare calendar date)."
},
"agreement_id": {
"type": "string",
"description": "The agreement to edit."
},
"customer_name": {
"type": "string",
"description": "New counterparty / customer name."
},
"accrual_cadence": {
"type": "string",
"description": "How often to accrue: realtime | daily | weekly | monthly | per_event."
},
"settlement_cadence": {
"type": "string",
"description": "How often it settles: weekly | semi_monthly | monthly | quarterly | semi_annual | annual | threshold | ad_hoc."
}
},
"additionalProperties": false
}Change the RATES on a rate-routed (dimension-routed) agreement — a regime's flat rate, a tiered regime's own ladder, or the shared tier ladder. Rates are given in PERCENT (1.5 = 1.5%); thresholds in dollars. Call WITHOUT confirm first to DRY-RUN: with no edits it LISTS the current regimes (their keys + rates) so you know what to change; with edits it echoes the intended change. Call again with confirm:true to apply. On apply the new rate goes live for future transactions immediately, and — because it moves money on already-accrued periods — a gated Recalculate card is raised that the operator approves in the workspace (the past-period adjustment posts only on approval; nothing is backdated through you). Structure (routing dimension, regime keys, member values) is NOT editable here — only rates. Refuses if posted to the ERP (supersede instead). Needs the agreement_id. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| confirm | boolean | Omit/false to DRY-RUN (list current rates or echo the change); true to apply and raise the gated Recalculate card. |
| regimes | array | Per-regime rate edits, keyed by the regime's key (from the dry-run list). Give flat_rate_pct for a flat regime, or tiers for a tiered regime's own ladder. |
| agreement_id* | string | The rate-routed agreement to edit. |
| shared_tier_grid | array | The shared tier ladder (used by tiered regimes that tier on the whole book). Thresholds in dollars, rate in percent. |
{
"type": "object",
"required": [
"agreement_id"
],
"properties": {
"confirm": {
"type": "boolean",
"description": "Omit/false to DRY-RUN (list current rates or echo the change); true to apply and raise the gated Recalculate card."
},
"regimes": {
"type": "array",
"items": {
"type": "object",
"required": [
"key"
],
"properties": {
"key": {
"type": "string",
"description": "The regime key (e.g. STANDARD_L2, VPP)."
},
"tiers": {
"type": "array",
"items": {
"type": "object",
"required": [
"threshold",
"rate_pct"
],
"properties": {
"rate_pct": {
"type": "number"
},
"threshold": {
"type": "number"
}
},
"additionalProperties": false
},
"description": "This regime's own tier ladder (tiered regimes that don't use the shared grid)."
},
"flat_rate_pct": {
"type": "number",
"description": "New flat rate in percent (0.5 = 0.50%). Flat regimes only."
}
},
"additionalProperties": false
},
"description": "Per-regime rate edits, keyed by the regime's key (from the dry-run list). Give flat_rate_pct for a flat regime, or tiers for a tiered regime's own ladder."
},
"agreement_id": {
"type": "string",
"description": "The rate-routed agreement to edit."
},
"shared_tier_grid": {
"type": "array",
"items": {
"type": "object",
"required": [
"threshold",
"rate_pct"
],
"properties": {
"rate_pct": {
"type": "number"
},
"threshold": {
"type": "number"
}
},
"additionalProperties": false
},
"description": "The shared tier ladder (used by tiered regimes that tier on the whole book). Thresholds in dollars, rate in percent."
}
},
"additionalProperties": false
}Report where an engagement stands — derived from the engagement file's real events, not a stored status. With an engagement id, it shows which steps are on the chain, what's next, and any open items (the close can't be signed while any remain). With no id, it lists the client's engagements and the firm's own status. If the file's hash chain fails re-verification it refuses to report rather than vouch for a tampered record.
| Argument | Type | Description |
|---|---|---|
| engagement_id | string | The engagement to report on. Omit to list all engagements + the firm status. |
{
"type": "object",
"properties": {
"engagement_id": {
"type": "string",
"description": "The engagement to report on. Omit to list all engagements + the firm status."
}
},
"additionalProperties": false
}State the governed US-GAAP treatment FOR A PAYMENT TYPE — a rebate, incentive, chargeback, or trade-spend payment — under ASC 606 (customer rebate / consideration payable to a customer / variable consideration), ASC 705-20 (vendor rebate), or ASC 340-40 (sales commission). It CLASSIFIES the payment and returns the governed treatment, the exact ASC citation, and the rule applied — deterministic and grounded, it will not guess and asks which payment type applies when unclear. It is NOT a free-form accounting Q&A or advisory debate: it does not argue a position, weigh a contrary opinion, or answer open questions beyond the payment-type classification (the `scenario` text is context only). For anything past the treatment of a payment type, run the engagement (compose/ingest the agreement, then compute).
| Argument | Type | Description |
|---|---|---|
| payment | string | The nature of the payment. customer_rebate = you pay/credit your customer (sell side); spa_or_billback = a special pricing agreement / billback credit to the customer; chargeback = a channel chargeback / price protection; vendor_rebate = a vendor pays/credits you (buy side); internal_commission = you pay your own salesperson. Omit if unknown and the tool will return the options to choose from. |
| scenario | string | Optional free-text description of the user's scenario, for context. |
| fair_value_cap_usd | number | Required only when buys_distinct_good_or_service is true: the fair value of that distinct good/service. The payment is a purchase only up to fair value; any excess reverts to the default treatment. |
| buys_distinct_good_or_service | boolean | True if the payment is in exchange for a distinct good or service the counterparty actually transfers (e.g. advertising, data, slotting with proof-of-performance), as opposed to a plain price concession. This can reclassify the treatment (ASC 606-10-32-26 / 705-20-25-2). |
{
"type": "object",
"properties": {
"payment": {
"enum": [
"customer_rebate",
"spa_or_billback",
"chargeback",
"vendor_rebate",
"internal_commission"
],
"type": "string",
"description": "The nature of the payment. customer_rebate = you pay/credit your customer (sell side); spa_or_billback = a special pricing agreement / billback credit to the customer; chargeback = a channel chargeback / price protection; vendor_rebate = a vendor pays/credits you (buy side); internal_commission = you pay your own salesperson. Omit if unknown and the tool will return the options to choose from."
},
"scenario": {
"type": "string",
"description": "Optional free-text description of the user's scenario, for context."
},
"fair_value_cap_usd": {
"type": "number",
"description": "Required only when buys_distinct_good_or_service is true: the fair value of that distinct good/service. The payment is a purchase only up to fair value; any excess reverts to the default treatment."
},
"buys_distinct_good_or_service": {
"type": "boolean",
"description": "True if the payment is in exchange for a distinct good or service the counterparty actually transfers (e.g. advertising, data, slotting with proof-of-performance), as opposed to a plain price concession. This can reclassify the treatment (ASC 606-10-32-26 / 705-20-25-2)."
}
},
"additionalProperties": false
}Put together the auditor-ready package for your tenant: the open accrual you can stand behind (earned → settled → open), where margin is leaking versus what's sitting outside any program, and sample lineage tracing back to source — all computed off the canonical ledger. Requires a connected Aurgus account.
No arguments.
{
"type": "object",
"properties": {},
"additionalProperties": false
}Deliver the engagement workpapers — the certified figures and the open-items register on one page, from the hash-chained engagement file. Refuses until a principal has signed the close. This is the auditor-ready deliverable: what was concluded, and what could not be proven, together.
| Argument | Type | Description |
|---|---|---|
| engagement_id* | string | The engagement to deliver workpapers for. |
{
"type": "object",
"required": [
"engagement_id"
],
"properties": {
"engagement_id": {
"type": "string",
"description": "The engagement to deliver workpapers for."
}
},
"additionalProperties": false
}Call this when the user asks for help or how to use Aurgus — 'Aurgus help', 'help', 'what can you do', 'how do I use this', 'show me the manual', 'what are the commands / trigger words'. Returns the Aurgus manual: what it is, how an engagement runs step by step, the trigger phrases that fire each tool, and how to start. Free, no account needed.
No arguments.
{
"type": "object",
"properties": {},
"additionalProperties": false
}Hand Aurgus one of your three rebate files (CSV) to read into your tenant: 'pos' (your POS / sell-through extract — what was earned), 'claims' (the claims you submitted), or 'credits' (credit memos / vendor invoices you received). Give it the raw CSV, which kind of file it is, and a note of which of your columns maps to which Aurgus field. Rows with blank or bad amounts are held and reported back to you — never quietly booked as $0 — and nothing touches your numbers until a person certifies the mapping. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| csv* | string | The raw CSV content of your extract (header row + data rows). |
| kind | string | Which file this is: 'pos' (sales/POS extract — earned), 'claims' (claims submitted), or 'credits' (credit memos / vendor invoices received). Defaults to 'pos'. |
| mapping* | object | Map each of your column headers to an Aurgus field. pos fields: source_transaction_id, transaction_at, end_customer_id, material_id, amount_usd, distributor_id, quantity. claims fields: source_claim_id, claim_type, amount_claimed_usd, claim_date, end_customer_id, material_id. credits fields: source_credit_id, amount_credited_usd, credit_date, end_customer_id, material_id. Example: {"Invoice #":"source_transaction_id","Net Sales":"amount_usd"}. |
| filename | string | Optional original filename. |
{
"type": "object",
"required": [
"csv",
"mapping"
],
"properties": {
"csv": {
"type": "string",
"description": "The raw CSV content of your extract (header row + data rows)."
},
"kind": {
"enum": [
"pos",
"claims",
"credits"
],
"type": "string",
"description": "Which file this is: 'pos' (sales/POS extract — earned), 'claims' (claims submitted), or 'credits' (credit memos / vendor invoices received). Defaults to 'pos'."
},
"mapping": {
"type": "object",
"description": "Map each of your column headers to an Aurgus field. pos fields: source_transaction_id, transaction_at, end_customer_id, material_id, amount_usd, distributor_id, quantity. claims fields: source_claim_id, claim_type, amount_claimed_usd, claim_date, end_customer_id, material_id. credits fields: source_credit_id, amount_credited_usd, credit_date, end_customer_id, material_id. Example: {\"Invoice #\":\"source_transaction_id\",\"Net Sales\":\"amount_usd\"}."
},
"filename": {
"type": "string",
"description": "Optional original filename."
}
},
"additionalProperties": false
}Hand Aurgus your rebate agreement — PASTE its text, or DROP a PDF/scanned document (pass it as file_base64). Aurgus reads the terms with its deterministic parser (and CV/OCR for a PDF/scan — a Python CPU service, ZERO LLM): customer, basis (whole-volume / incremental / cliff), rate or tier ladder, and the rebate period. A CPU parser proposes spans, deterministic rules produce every value, and anything it can't read cleanly is flagged for your eye rather than guessed. Nothing is created until a person reviews and certifies the terms in the browser — this is how the agreement (and the ASC 606 treatment it implies) gets set up, before any transaction data is asked for.
| Argument | Type | Description |
|---|---|---|
| text | string | The agreement's text (paste the full agreement, or the rebate clauses). Provide this OR file_base64. |
| filename | string | The original filename (e.g. 'rebate-agreement.pdf') — used to sniff the file type and shown on the review page. |
| file_base64 | string | A PDF or scanned-image agreement, base64-encoded. Aurgus reads it with CV/OCR (zero LLM). Provide this OR text. |
{
"type": "object",
"properties": {
"text": {
"type": "string",
"description": "The agreement's text (paste the full agreement, or the rebate clauses). Provide this OR file_base64."
},
"filename": {
"type": "string",
"description": "The original filename (e.g. 'rebate-agreement.pdf') — used to sniff the file type and shown on the review page."
},
"file_base64": {
"type": "string",
"description": "A PDF or scanned-image agreement, base64-encoded. Aurgus reads it with CV/OCR (zero LLM). Provide this OR text."
}
},
"additionalProperties": false
}List the saved analytics reports on this tenant (name + what each measures). Use `run_report` with a name to re-run one. Requires a connected Aurgus account.
No arguments.
{
"type": "object",
"properties": {},
"additionalProperties": false
}Open a revenue-management engagement for a client. Capture the intake — the client entity, the period, the program(s), the sources of truth, and who will certify — and start the engagement file (a hash-chained, append-only record of everything that follows). This is how a firm begins: a named client and a scope, before any numbers. The agreement comes next; nothing is computed here.
| Argument | Type | Description |
|---|---|---|
| entity* | string | The client entity we're closing for (e.g. 'Acme Distribution'). |
| period | string | The close period (e.g. 'Q3 2026'). |
| programs | array | The rebate / SPA / billback program(s) in scope, if known. |
| direction | string | Which side the client is on for a billback / chargeback / rebate: 'paying' (sell-side → ASC 606) or 'receiving' (buy-side → ASC 705-20). Omit if not yet known — Aurgus will ask rather than assume the treatment. |
| who_certifies | string | Who on the client side will certify the terms and mapping (name or email). |
| sources_of_truth | array | The client's systems of record for this close. |
{
"type": "object",
"required": [
"entity"
],
"properties": {
"entity": {
"type": "string",
"description": "The client entity we're closing for (e.g. 'Acme Distribution')."
},
"period": {
"type": "string",
"description": "The close period (e.g. 'Q3 2026')."
},
"programs": {
"type": "array",
"items": {
"type": "string"
},
"description": "The rebate / SPA / billback program(s) in scope, if known."
},
"direction": {
"type": "string",
"description": "Which side the client is on for a billback / chargeback / rebate: 'paying' (sell-side → ASC 606) or 'receiving' (buy-side → ASC 705-20). Omit if not yet known — Aurgus will ask rather than assume the treatment."
},
"who_certifies": {
"type": "string",
"description": "Who on the client side will certify the terms and mapping (name or email)."
},
"sources_of_truth": {
"type": "array",
"items": {
"type": "string"
},
"description": "The client's systems of record for this close."
}
},
"additionalProperties": false
}The engagement's open-items register — the things the close can't yet account for (a document not received, a term not found in the agreement, an unmatched figure). List them, open a new one, or resolve one by id. The register ships alongside the certified figures; no gap is ever filled on the client's behalf, and the close cannot be signed while any item remains open.
| Argument | Type | Description |
|---|---|---|
| item | string | For action=open: the open item's description. |
| owner | string | For action=open: who owns resolving it. |
| action | string | list (default), open a new item, or resolve one. |
| item_id | string | For action=resolve: the id of the item being resolved. |
| engagement_id* | string | The engagement whose register to act on. |
{
"type": "object",
"required": [
"engagement_id"
],
"properties": {
"item": {
"type": "string",
"description": "For action=open: the open item's description."
},
"owner": {
"type": "string",
"description": "For action=open: who owns resolving it."
},
"action": {
"enum": [
"list",
"open",
"resolve"
],
"type": "string",
"description": "list (default), open a new item, or resolve one."
},
"item_id": {
"type": "string",
"description": "For action=resolve: the id of the item being resolved."
},
"engagement_id": {
"type": "string",
"description": "The engagement whose register to act on."
}
},
"additionalProperties": false
}Recalculate — re-run the deterministic engine over the POS data, dispatching every row against the agreement(s) so rows that just became eligible (e.g. after a data fix or a rule change) accrue. Posts provisional accruals (the same engine compute_close uses); rows that already have a positive accrual are skipped (idempotent). Pass agreement_id to recompute ONE agreement, or omit it to recompute ALL active agreements. Returns the events created and the accrual total. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| agreement_id | string | Recompute just this agreement. Omit to recompute all active agreements. |
{
"type": "object",
"properties": {
"agreement_id": {
"type": "string",
"description": "Recompute just this agreement. Omit to recompute all active agreements."
}
},
"additionalProperties": false
}Receive a client document into an engagement BY REFERENCE — a client-granted signed https link (or an upload handle), never the file's contents. The engine fetches it server-side, stages it inside the client's tenant for certification, and tells you only the column names and where to certify the mapping — no row of the client's data ever passes through the model. Resolves the matching PBC open item. This is how the data gets in without it ever touching the model: 'no LLM on the money path' stays literally true.
| Argument | Type | Description |
|---|---|---|
| kind* | string | Which stream this is (pos = sell-through, claims = billbacks, credits = credit memos). |
| signed_url | string | A client-granted signed https link to the file (e.g. a Drive/SharePoint export). The engine fetches it directly; you do NOT paste the file contents. |
| engagement_id* | string | The engagement this document belongs to. |
| upload_handle | string | Alternatively, a handle to a file already uploaded to the client's tenant store. |
{
"type": "object",
"required": [
"engagement_id",
"kind"
],
"properties": {
"kind": {
"enum": [
"pos",
"claims",
"credits"
],
"type": "string",
"description": "Which stream this is (pos = sell-through, claims = billbacks, credits = credit memos)."
},
"signed_url": {
"type": "string",
"description": "A client-granted signed https link to the file (e.g. a Drive/SharePoint export). The engine fetches it directly; you do NOT paste the file contents."
},
"engagement_id": {
"type": "string",
"description": "The engagement this document belongs to."
},
"upload_handle": {
"type": "string",
"description": "Alternatively, a handle to a file already uploaded to the client's tenant store."
}
},
"additionalProperties": false
}What's new in Aurgus and how to stress-test it — call this for 'what changed', 'release notes', 'what's new', 'changelog', or if you're reviewing/pressure-testing the product. Returns the current release summary (reuse-first institutional knowledge, document/PDF intake, the anti-hallucination guards, ASC coverage) plus a concrete test checklist. Free, no account needed, reads nothing from any tenant.
No arguments.
{
"type": "object",
"properties": {},
"additionalProperties": false
}The portfolio report — every active agreement on the tenant (or one, by id), with its earned / settled / open accrual, basis, status, and when it last calculated. This is the book-at-a-glance a controller watches: which agreements are live, what each has earned vs paid out, and what is open. Pass agreement_id for a single agreement, or status to filter the list (active / draft / closed / superseded). Read-only — it computes nothing new, it reports the canonical ledger. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| status | string | Filter the list by lifecycle status. Default: active. |
| agreement_id | string | Report on ONE agreement by id. Omit for the whole book. |
{
"type": "object",
"properties": {
"status": {
"enum": [
"active",
"draft",
"closed",
"superseded",
"all"
],
"type": "string",
"description": "Filter the list by lifecycle status. Default: active."
},
"agreement_id": {
"type": "string",
"description": "Report on ONE agreement by id. Omit for the whole book."
}
},
"additionalProperties": false
}Draft the PBC (prepared-by-client) document list for an engagement, FROM its agreement — the program decides which files the close needs (a sell-side rebate → the POS / sell-through extract; a buy-side billback → the claims file), never a generic ask. Each requested document is logged as an open item; the close can't be signed until every one is received, mapped and certified. Needs an active agreement first (the agreement is the rulebook).
| Argument | Type | Description |
|---|---|---|
| engagement_id* | string | The engagement to draft the PBC list for. |
{
"type": "object",
"required": [
"engagement_id"
],
"properties": {
"engagement_id": {
"type": "string",
"description": "The engagement to draft the PBC list for."
}
},
"additionalProperties": false
}Get the link to run a real close on your OWN numbers — bring a rebate / SPA / deduction extract and get back audit-defensible accruals, full lineage, and an auditor-ready export, with nothing posted to your GL. Use this when the user is ready to move from a sample to their own data. Optionally takes a work email to set up access — only what the user volunteers, and never ask for financial data inside the chat.
| Argument | Type | Description |
|---|---|---|
| string | Optional work email to set up access / follow up. Only pass what the user volunteers. | |
| scenario | string | Optional short description of what the user wants to run. |
{
"type": "object",
"properties": {
"email": {
"type": "string",
"description": "Optional work email to set up access / follow up. Only pass what the user volunteers."
},
"scenario": {
"type": "string",
"description": "Optional short description of what the user wants to run."
}
},
"additionalProperties": false
}Re-run a SAVED analytics report by name on current data — returns the grouped rows + total, governed and read-only exactly like `analyze`. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| name* | string | The saved report's name (see `list_reports`). |
{
"type": "object",
"required": [
"name"
],
"properties": {
"name": {
"type": "string",
"description": "The saved report's name (see `list_reports`)."
}
},
"additionalProperties": false
}Save an analytics report for reuse. Give it a NAME plus the same measure / group_by (/ dimension_key / agreement_id) you'd pass to `analyze` — the governed spec is stored under that name (re-saving the same name updates it). Later, `run_report` re-runs it on current data. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| name* | string | A name to save this report under (e.g. 'Rebate by class'). |
| measure* | string | accrued | settled | basis | count. |
| group_by* | string | agreement | class (needs dimension_key) | month | quarter. |
| agreement_id | string | Optional — restrict to one agreement. |
| dimension_key | string | Required when group_by='class' — e.g. interchange_class. |
{
"type": "object",
"required": [
"name",
"measure",
"group_by"
],
"properties": {
"name": {
"type": "string",
"description": "A name to save this report under (e.g. 'Rebate by class')."
},
"measure": {
"enum": [
"accrued",
"settled",
"basis",
"count"
],
"type": "string",
"description": "accrued | settled | basis | count."
},
"group_by": {
"enum": [
"agreement",
"class",
"month",
"quarter"
],
"type": "string",
"description": "agreement | class (needs dimension_key) | month | quarter."
},
"agreement_id": {
"type": "string",
"description": "Optional — restrict to one agreement."
},
"dimension_key": {
"type": "string",
"description": "Required when group_by='class' — e.g. interchange_class."
}
},
"additionalProperties": false
}Set how often an agreement ACCRUES and SETTLES. Ask the user these when setting an agreement up (or to change them later): (1) how often to accrue — 'realtime' as sales land, or batched 'daily' / 'weekly' / 'monthly' / 'per_event'; (2) how often it settles — when the money actually hits their account — 'weekly', 'semi_monthly', 'monthly', 'quarterly', 'semi_annual', 'annual', 'threshold' (when a dollar threshold is hit), or 'ad_hoc'. Pass the agreement_id and whichever cadence(s) the user chose; you can set one or both. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| agreement_id* | string | The agreement whose cadence to set. |
| accrual_cadence | string | How often to accrue. 'realtime' = as each sale lands. |
| settlement_cadence | string | How often it settles — when the rebate is actually paid out. |
| settlement_approver_email | string | If someone must APPROVE each settlement before money moves, their email. Aurgus holds every settlement and emails them a one-time confirm link; nothing settles until they approve. Pass an empty string to turn the approval requirement off. |
{
"type": "object",
"required": [
"agreement_id"
],
"properties": {
"agreement_id": {
"type": "string",
"description": "The agreement whose cadence to set."
},
"accrual_cadence": {
"enum": [
"realtime",
"daily",
"weekly",
"monthly",
"per_event"
],
"type": "string",
"description": "How often to accrue. 'realtime' = as each sale lands."
},
"settlement_cadence": {
"enum": [
"weekly",
"semi_monthly",
"monthly",
"quarterly",
"semi_annual",
"annual",
"threshold",
"ad_hoc"
],
"type": "string",
"description": "How often it settles — when the rebate is actually paid out."
},
"settlement_approver_email": {
"type": "string",
"description": "If someone must APPROVE each settlement before money moves, their email. Aurgus holds every settlement and emails them a one-time confirm link; nothing settles until they approve. Pass an empty string to turn the approval requirement off."
}
},
"additionalProperties": false
}Settle an agreement — post the PAYOUT. Creates per-bucket Settlement event(s) totalling the open accrual (earned − already settled), moving the open balance to $0. This is the money-OUT step (distinct from compute_close, which accrues, and true_up, which reconciles the accrual to a prior settlement). Call WITHOUT confirm to DRY-RUN — it reports the open accrual that would be paid and any gate that blocks it (a named settlement approver, an incomplete agreement, or an anomaly hold). Call again with confirm:true to post it. Governed by the SAME gates as the workspace Settle button (one core). Needs the agreement_id. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| confirm | boolean | Omit/false to DRY-RUN (preview the payout + any blocking gate); true to post the Settlement event(s). |
| agreement_id* | string | The agreement to settle (pay out its open accrual). |
{
"type": "object",
"required": [
"agreement_id"
],
"properties": {
"confirm": {
"type": "boolean",
"description": "Omit/false to DRY-RUN (preview the payout + any blocking gate); true to post the Settlement event(s)."
},
"agreement_id": {
"type": "string",
"description": "The agreement to settle (pay out its open accrual)."
}
},
"additionalProperties": false
}A principal signs the governed close for an engagement, by name, on the engagement file. It refuses while any open item remains — the open-items register gates the signature — and a close must have been computed. You cannot sign on the client's behalf; the person signs. Signing is what releases the workpapers.
| Argument | Type | Description |
|---|---|---|
| engagement_id* | string | The engagement whose close is being signed. |
{
"type": "object",
"required": [
"engagement_id"
],
"properties": {
"engagement_id": {
"type": "string",
"description": "The engagement whose close is being signed."
}
},
"additionalProperties": false
}Walk any accrued figure all the way back to where it came from — source row → eligibility → bucket → rate → rule → event chain — for a given transaction. This is how you show an auditor exactly why a number is what it is. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| agreement_id | string | Optional — limit to one agreement; otherwise all agreements that fired on the row. |
| source_transaction_id* | string | The transaction id to trace. |
{
"type": "object",
"required": [
"source_transaction_id"
],
"properties": {
"agreement_id": {
"type": "string",
"description": "Optional — limit to one agreement; otherwise all agreements that fired on the row."
},
"source_transaction_id": {
"type": "string",
"description": "The transaction id to trace."
}
},
"additionalProperties": false
}True-up an agreement — AFTER a settlement, match the accrual account to what was ACTUALLY settled. Posts ONE Adjustment (signed = settled − earned) in the CURRENT period so earned equals settled and the open balance nets to $0. Over-accrued → a negative Adjustment; under-accrued → a positive one. Always current-period, never backdated. Append-only and idempotent (a second run finds it already matched). Call WITHOUT confirm to DRY-RUN (shows the exact Adjustment and the before/after); call again with confirm:true to apply. This is also the first step of a close-out (close does the true-up then flags the agreement closed). Needs the agreement_id. Requires a connected Aurgus account.
| Argument | Type | Description |
|---|---|---|
| confirm | boolean | Omit/false to DRY-RUN (preview the Adjustment); true to post it. |
| agreement_id* | string | The agreement to true up. |
{
"type": "object",
"required": [
"agreement_id"
],
"properties": {
"confirm": {
"type": "boolean",
"description": "Omit/false to DRY-RUN (preview the Adjustment); true to post it."
},
"agreement_id": {
"type": "string",
"description": "The agreement to true up."
}
},
"additionalProperties": false
}We read every tool's name, description and inputs the way the model will, looking for instructions hidden from you. A clean result means no warning signs, not a guarantee. Scanned Nov 1, 2026.