Skip to main content
DualEntry applies the same controls to AI actions that it applies to people. A record that Accounting Intelligence or the DualEntry MCP server creates goes through your approval workflows, your role permissions, and your period locks, and every change lands in the audit trail. Changes Accounting Intelligence makes in a conversation are labeled as the agent acting for you; changes made through MCP are recorded under the connected user’s name. This page explains how each control applies, so you can describe them to an auditor or design your workflows around them. Two AI surfaces write to DualEntry. Accounting Intelligence is the assistant inside DualEntry; see How Accounting Intelligence Works. The DualEntry MCP server lets an outside AI client, such as Claude, read and write your data through your account; see MCP Server: Tools, Permissions, and Troubleshooting.

​
Approval workflows apply to AI-created records

An approval workflow evaluates a record the same way whether a person, the API, Accounting Intelligence, or an MCP client submitted it. DualEntry runs one approval check whenever a record is submitted to post, and AI surfaces call that same check rather than a separate path. Saving a draft or archiving a record does not run the check. No role is exempt by default, including organization admins. Whether a policy applies depends only on its conditions, such as record type, company, amount, or the submitting user’s role. A policy written to match every journal entry over $10,000 catches an admin’s AI-assisted entry exactly as it catches a staff accountant’s manual one. If you want a role excluded, you have to write that into the policy’s conditions. Some integrations can be excluded from approval policies through a per-integration setting. AI surfaces cannot. Neither Accounting Intelligence nor an MCP client is treated as an integration for this purpose, so there is no setting that lets AI-created records skip approval. When a policy matches, the record stays in draft with no GL impact until every stage approves, and DualEntry posts it at that point. When no policy matches, the record posts on submit, the same as a manual record with no matching policy.

​
When an AI-created record enters approval

Approval policies are checked when a record is submitted to post, not while it is a draft. What matters is therefore who submits the record, and the two AI surfaces differ here. Accounting Intelligence drafts new records for you to save. When you ask it to create a journal entry, bill, invoice, or other transaction, it returns a draft in the conversation. Nothing is saved until you review the draft and save it yourself. Saving submits the record under your name, through the same path as a record you entered by hand, and your approval policies apply at that moment. See Drafting journal entries. Setup objects created in a conversation work differently. An approval workflow, a bank rule, a recurring journal entry schedule, or an anomaly detector is saved as soon as you choose Approve on the card Accounting Intelligence shows, with no separate save step. A reconciliation it starts is created right away, without a card. An MCP client submits records directly. The MCP save_record tool creates a real record, and for most record types it submits the record to post unless the client sends record_status as draft. If an approval policy matches, the record waits for approval in DualEntry. If none matches, it posts immediately, with no preview step inside DualEntry. For a worked example that has the client show the entry before posting, see How to Post a Period-End Accrual from Claude. If you connect an MCP client to DualEntry and want a review gate on everything it creates, add an approval policy that matches those record types.

​
Who counts as the submitter for separation of duties

Separation of duties needs to know who created a record, and for AI actions DualEntry uses the person the AI acted for. The AI is never treated as an independent submitter that could satisfy an approval requirement on its own.
  • Accounting Intelligence: The submitter is the person in the conversation. If you save a draft it prepared, you are the submitter.
  • MCP: The submitter is the DualEntry user whose account the MCP client is connected with.
With separation of duties turned on, DualEntry removes that person from the approver pool, the same as for a manual record. When a stage resolves only to that person, it falls back to other organization admins, and if there are none, the record cannot advance. With separation of duties off, a policy can allow self-approval: when the submitter is also an approver on the current stage, DualEntry applies their approval automatically. MCP is the exception. A record submitted through MCP is never self-approved, because the person did not review it inside DualEntry. It waits for the approver to act in DualEntry, even when that approver is the same person who connected the MCP client.

​
What AI can change in existing records

Beyond creating records, both AI surfaces can change existing ones, within the permissions of the person they act for. Neither surface can permanently delete a record. Accounting Intelligence, in a conversation, can update and archive records that your role lets you edit and archive. Archiving is the furthest it goes; archived records remain in DualEntry and in the audit trail. Higher-impact actions pause the conversation on a card, and nothing happens until you choose Approve:
  • Reversing a journal entry
  • Swapping a record’s attachment
  • Updating a customer, vendor, or item
  • Merging accounts, mass-applying a field value, or applying a bulk reclassification
  • Scheduling a recurring journal entry
  • Locking a period, finalizing a reconciliation, applying bank matches, and saving or deleting bank rules
  • Creating, changing, or rerouting approval workflows
Accounting Intelligence can approve or reject a record only where you are an assigned approver on that record’s current stage. In the approval history the action is listed under your name. In the audit trail, a final approval or a rejection made this way shows as the agent acting on your behalf, so it reads differently from one you click yourself. The DualEntry MCP server exposes tools to create records and entities, update records and some entity types, and manage bank matches, contracts, fixed assets, and quotes. It has no tool to approve, reject, reverse, or delete a record. Its update_record tool refuses line or amount changes on a posted journal entry. For the full tool list and the permission each one checks, see MCP Server: Tools, Permissions, and Troubleshooting.

​
Permissions and period locks apply to every AI action

Every AI action runs under a real user’s access, so an AI surface can never do more than that person could do in the app.
  • Role permissions: Each AI action checks the same role permission a person would need: create to create a record, edit to change one, archive to archive one. A user without edit access to bills cannot have AI edit a bill.
  • Company scope: A user restricted to certain companies through entity scoping can only have AI read or write records in those companies.
  • Scheduled agents: A scheduled agent runs under the permissions of the user who owns it, and is barred from a further set of actions that need someone present.
  • Period locks: A locked period blocks AI writes the same way it blocks manual ones. The check runs when the transaction is saved, so no AI tool can work around it.
Revoking a user’s MCP connection stops further MCP writes on their behalf immediately.

​
Tracing an AI-created entry for an audit

An auditor can follow an AI-created entry from creation to posting using the record’s audit trail and its approval history. The two together show who acted, which policy applied, and who approved. The actor on each audit event depends on how the change was made: To trace a single entry:
  1. Open the record’s audit trail and find the creation event. The actor shows who submitted the record, per the table above.
  2. Open the record’s approval history. Each stage lists the approver, the action, the time, and the rejection reason where there is one. Approval history lists the approver only, so it does not show whether Accounting Intelligence acted for them. The audit trail does: the final approval and any rejection appear there, and one made by Accounting Intelligence shows as the agent on the approver’s behalf.
  3. Find the status change to Posted in the audit trail. It follows the final approval, or the submission itself when no policy matched.
The audit trail is append-only, so none of these events can be edited or removed afterward, by a person or by AI.

​
Where AI conversations are kept

The audit trail records what changed in your data, not the conversation that led to it. Your prompts and Accounting Intelligence’s responses are stored as chat history, separately from the audit trail. A conversation is private to the person who started it unless they share it with the organization. Organization admins cannot open another user’s private conversations. Closing a conversation removes it from your chat list but keeps its history. When an auditor needs the reasoning behind an AI change, not just the change itself, the person who had the conversation can share it with the organization so reviewers can read the prompts and responses alongside the audit trail. Each scheduled agent run keeps its own conversation, listed on that agent’s runs list, so the output of an unattended run can be reviewed the same way. Calls Accounting Intelligence makes through a connector are logged separately with metadata only: which tool ran, who ran it, and whether it succeeded. For how conversation data is stored and which providers process it, see the AI Data Handling FAQ.
Last modified on October 15, 2026