Manual adjustment proposal skill

Sample skill for investigating, proposing, confirming, and verifying manual ledger adjustments.

This sample separates investigation from execution. Manual transaction tools are feature-gated and appear only when the workspace and session allow them.

Copy this skill

---
name: manual-adjustment-proposal
description: Investigate a requested ledger adjustment, produce an exact proposal, and write it only after explicit confirmation.
---

# Manual adjustment proposal

1. Start in read-only mode. Confirm the legal entity, accounting month, currency, business reason, source evidence, and intended financial effect.
2. Use `get_entity_transactions_browse` to inspect the relevant existing entries with bounded dates and filters.
3. Resolve or require the exact local account and counter-account codes for that entity. Do not guess codes from account names.
4. Propose the smallest set of manual rows needed. Show entity, month, account, counter-account, signed value, currency, dimensions, description, source reference, and the expected net effect.
5. Check that the proposal is internally consistent and does not duplicate an existing manual row or source transaction.
6. Stop for explicit user confirmation. Do not call a write tool while the request is ambiguous or the proposal is still changing.
7. After confirmation, re-read the relevant transactions and repeat the duplicate check. Because ledger visibility is asynchronous, treat this check as advisory rather than proof that no matching transaction exists. If the data changed in a way that affects the proposal or a matching source transaction now exists, stop, show a revised proposal, and request confirmation again.
8. If the proposal is still valid and this confirmed proposal has not already been submitted, call `create_manual_transaction` for one row or `create_manual_transactions` for several rows. Use the stable, unique client request ids from the confirmed proposal, and reuse those exact ids for every retry or resumed execution of that proposal.
9. Inspect every returned row result. Treat `created: true` plus the returned transaction id as confirmation that the write was accepted. A bulk call can partially succeed; do not retry successful rows under new ids.
10. Explain that ledger visibility is asynchronous. After allowing time for downstream processing, re-read the affected period with `get_entity_transactions_browse` and reconcile the created rows and intended financial effect. If an accepted row is not visible yet, report it as pending propagation; do not report the write as failed or retry it solely because the browse result is stale.

## Rules

- If the required create tool is absent from `tools/list`, stop and explain that manual writes are not enabled.
- Account and counter-account codes must belong to the exact entity.
- Never manufacture an adjustment solely to force a report to a desired total.
- Do not infer tax, intercompany, currency, or dimension treatment without reviewed instructions.
- Preserve returned transaction ids and client request ids for reconciliation or a later approved reversal.
- If the create response is ambiguous, retry only with the same client request id so the operation remains idempotent.
- Deletion or reversal is a separate destructive workflow and requires a new explicit confirmation.

## Output

Before confirmation, return an adjustment proposal and validation checklist. After execution, return accepted and failed rows, ids, ledger-propagation status, reconciliation evidence when available, and any residual discrepancy.

Try it

Investigate Norwegian salaries posted to the intercompany account in June and propose a correcting manual transaction. Do not write it yet.

Prepare twelve monthly accrual rows from this approved schedule and show the exact batch before asking me to confirm.

Check whether the confirmed adjustment has propagated to the entity’s July transactions. If it is not visible yet, report it as pending rather than retrying the write.

Manual transactions affect financial reporting only after downstream processing. Always retain the proposal, confirmation, and returned identifiers; reconcile the ledger after propagation without treating temporary absence as a failed write.