create_accounting_run

Every new run requires one explicitly assigned entity and calendar tax_year in scope. Optional inclusive period_start/period_end must remain in that year. Unassigned source occurrences remain pending and excluded from amounts. Inspect catalog.scope_review, then resubmit with scope_assignments keyed by source document and original record number; raw receipts use record null. Bookings are caller decisions, never inferred. Conflicting source observations need an explicit review_note; wrong-entity/out-of-period assignments stay held. Canonical CSV may carry Assigned Entity,Booking Date,Scope Review Note columns. Use replaces_run_id for a scoped correction; the original history stays unchanged. Analyze supported textual accounting records with the pinned deterministic Writeoff engine and create a private, encrypted audit run owned by the caller. Accepted filenames end in .txt, .md, .text, .eml, .csv, .ofx, .qfx, or .qif. Returns estimates for review only: it does not file taxes, move money, or send data to an external accounting service. Send prepared rows, not raw document text. With Writeoff 0.1.5, recognized comma-column headers (including duplicate money labels and ($), $ or USD suffixes), adjacent decimal columns and partial numeric matches refuse with a source review error; no amount is counted for that source. Other text can still collapse to exactly ONE entry; unrecognized column boundaries can resemble genuine grouped currency. Reconcile every source and amount. A genuinely empty paste raises. Convert each document into canonical CSV first: a Date,Description,Amount header, then one row per economic event. The Description column carrying the merchant name alone is the cleanest form, and prose is not merely untidy -- it CHANGES the answer. The matcher runs over the whole description against a vocabulary that holds ordinary words as well as vendor names: paper, printer, ink, notebook, legal, consulting, subscription, hosting and domain each classify alone with no vendor present, and contact lens or reading glasses classify as a MEDICAL deduction. A memo line saying what was bought can therefore create a deduction the vendor name alone would not. Send the merchant, not a description of the purchase. Not every phrase matches -- weekly grocery run, haircut and banana all stay unclassified -- but plain English is not inert. Classification is separately gated by context_text, but that gate is PARTIAL, not an off switch. Leaving it empty suppresses only the rules that need a business to exist: business, meals, vehicle and home-office. The personal rules stay live whatever you send -- a bare contact lens still classifies with context_text empty, under the category name fsa_hsa rather than anything called medical, and donation and tuition classify the same way. An empty context is NOT a way to stop deductions being proposed. The business gate is a bare substring test, not a reading of what you wrote: it opens on a keyword anywhere in the text, so I do not own a business and This is a personal return, not a business each switch the business rules ON rather than off. Negation is not detected. Suppress those rules with an EMPTY context, never with a denial. Booking is independent of all of it -- a row books its amount whether or not it classifies, and classification decides only whether the row becomes a deduction candidate. State the direction of every row. A .csv is routed as a statement, so each row has to say whether money went out or came in. Send exactly Date,Description,Amount,Type -- the amount column named Amount, and a Type of Purchase for money out or Refund for money in. Separate the fields with COMMAS. The delimiter is sniffed from the header row, and a semicolon additionally switches the amount parser to the European convention where the comma is the decimal point and the dot is a thousands separator. In a semicolon-delimited file an ordinary -20.00 is therefore read as 2000.00 and -1234.56 as 123456.00 -- silently, with no error, a hundred times the real figure. Tab and pipe keep the dot decimal. Send these four charge columns, each once; the optional duplicate-review metadata columns described below are also supported. Order among the four does not matter -- all 24 arrangements of Date,Description,Amount,Type measured identical -- and duplicate CSV headers are rejected before any transactions are returned. Names are compared after Unicode NFKC normalization, trimming outer whitespace and casefolding, including unknown and repeated blank headings. No copy is chosen, even when the repeated columns contain equal values. A literal Amount protects the figures from same-direction ancillary debit- or credit-looking columns. A literal Amount beats one or more same-direction ancillary columns in either order, whether those cells are populated or blank. Those ancillary values are not silently substituted. Opposite-direction ancillary columns together form a complete pair and fail closed beside Amount. Schema arbitration happens before row direction; Type cannot rescue an ambiguous schema. After arbitration selects one money representation, row direction uses a recognized Type first. Only when Type is absent or unrecognized does a trailing CR or DR marker decide. Only when both are absent does the selected money heading or sign decide. Thus Purchase and Refund outrank a conflicting marker on an otherwise unambiguous schema; notably, Payment is unrecognized and preserves the fallback. Conflicting money representations fail closed instead of being chosen by header order. Distinct equal-ranked amount aliases, multiple equally ranked same-direction money headers without a literal Amount, an amount alias beside a separate debit/credit representation, a literal Amount beside a complete pair, and a third amount candidate beside a pair each produce a named ambiguous-money error. A complete Debit/Credit pair remains supported, but a row with both pair cells nonzero fails closed. On a row with neither recognized Type nor CR/DR marker, a negative debit is a reversal and remains credit, while a negative credit is never promoted to spend. Within one role vocabulary, exact matches still beat partial matches. Column roles remain isolated. Description prefers an ordinary non-role heading. If none exists, exactly one releasable semantic-directional heading such as Charge Description or Payment Memo may serve, but only when an independent money representation survives without it. Outside that semantic-directional exception, suppressed lower-tier money, date and type candidates remain reserved and cannot become Description merely because a stronger sibling won their original role. Structural composites such as Amount Details, Transaction Type Description and Debit Details, or multiple competing semantic candidates, cannot serve as Description; when only those remain, the file fails closed rather than poaching merchant text. A duplicate-heading source contributes no transactions or amounts and carries a correction in catalog.errors. Inspect those errors even when other valid files let the batch complete. Check the original export and give each column a unique name before submitting a corrected file; saved historical results are not rewritten. Type is matched against a fixed vocabulary, not read as free text. purchase, debit, charge, withdrawal and dr mean money out; refund, credit, deposit, return and cr mean money in. All eight spelled-out words resolve in the plural as well, but the two abbreviations do not: drs and crs are unrecognised and fall through to the amount CELL, so a crs row written negative books as SPEND, not as money in. Anything else -- notably Payment, money in on a card but out on a checking account -- counts as unstated, and the direction then falls to the amount CELL rather than to the sign alone. Write the amount as a plain signed number, with nothing else in the cell. A trailing DR or CR and accounting parentheses are not decoration, and what they do depends on the column holding them and on the parser the CONTENT selected -- NOT on the file suffix. Two separate things happen to such a cell, and BOTH are confined to the statem. It is categorised as a Write tool in the Meta Council MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

create_accounting_run accepts 8 parameters: name, scope, context, documents, marginal_rate, replaces_run_id, scope_assignments, duplicate_resolutions. Required: scope, documents. The full parameter table on this page comes from the server's own tool schema.

Register the Meta Council MCP server in PolicyLayer and add a rule for create_accounting_run: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Meta Council. Nothing to install.

create_accounting_run is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Yes. Add a rate_limit block to the create_accounting_run rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for create_accounting_run. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

create_accounting_run is provided by the Meta Council MCP server (https://meta-council.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.