ifr_period_end_batch

Process multiple IFRS calculations for a reporting period in one call — year-end, quarter-end, or month-end. REQUIRED: each item's input object must include an id field (e.g. { type:"ias37", input:{ id:"PROV-LEGAL-001", ...otherFields } }) — validated by the controller schema; stamped as Reference on every journal entry for that item. ACCOUNTING POLICY — build the accountingPolicy block BEFORE calling this tool. Required policy blocks by standard (add the block whenever that standard appears in items[]): ias2: { costFormula: "FIFO"|"WEIGHTED_AVERAGE"|"SPECIFIC_IDENTIFICATION" } · ias7: { presentationMethod: "INDIRECT"|"DIRECT", interestPaidClassification: "OPERATING"|"FINANCING", interestReceivedClassification: "OPERATING"|"INVESTING", dividendsReceivedClassification: "OPERATING"|"INVESTING", dividendsPaidClassification: "FINANCING"|"OPERATING" } · ias16: { measurementModel: "COST"|"REVALUATION" } · ias20: { grantPresentationMethod: "DEFERRED_INCOME"|"DEDUCTION_FROM_ASSET" } · ias38: { measurementModel: "COST"|"REVALUATION" } · ias40: { measurementModel: "COST"|"FAIR_VALUE" } · ifrs6: { explorationCostPolicy: "EXPENSE"|"CAPITALISE" }. Always include at top level: functionalCurrency, presentationCurrency, reportingDate, previousReportingDate. ASSEMBLY WORKFLOW — follow every step for every batch, even when standards seem obvious: (1) IDENTIFY — for each item whose standard is not explicitly named by the user, call ifr_what_standard({ description: "<plain-language item description>" }) to resolve the standard slug. Batch all unknown items in parallel. Skip only when the slug is unambiguous from the user's own text (e.g. "our IAS 16 factory building"). (2) SCHEMAS — for each distinct standard slug across all items, call ifr_schema({ standard: "<slug>" }) in parallel — one call per unique standard, not one per item. (3) BUILD INPUTS — in each schema response locate exampleRequests.default (or the closest exampleIndex key). Copy it verbatim as the input base for that item. Then overwrite every field with the user's actual values. Remove fields that provably do not apply (e.g. strip all revaluation fields when measurementModel is "COST"). Never guess or invent field names — every key in your input must come from the schema. (4) FREE VALIDATE LOOP — assemble all items[] plus the accountingPolicy block, then call ifr_batch_validate. This is free. It returns every missing or invalid field across the whole batch in one response. Fix all reported errors, call ifr_batch_validate again. Repeat until allValid: true. Never call ifr_period_end_batch until allValid is true — the validate loop costs zero credits. (5) CALCULATE — once allValid: true, submit the exact same items[] to ifr_period_end_batch with mode: "partial". On the (now rare) event that an item still returns validation_error, fix only that item and re-run the batch with only that item — never re-run items that already returned success. This 5-step pattern (identify → schemas → build → free-validate loop → calculate) is designed for first-call success on the billable step. The free-validate loop is the safety net that catches all remaining field errors before any credit is spent. FIELD GATES — two classes of required inputs with no engine defaults: (a) Boolean recognition gates must be explicitly true — absent or false = gate closed, no default-open behaviour. Examples: futureBenefitsProbable, hasPresentObligation, futureTaxableProfitProbable, enhancesAboveOriginallyAssessedStandard, HBAU triad (IFRS 13), costsToObtainRecoverable (IFRS 15). (b) Numeric measurement inputs must be explicit — discountRate (IFRS 13 DCF), yearsToSettlement (IAS 37), usefulLifeYears/relatedAssetUsefulLife (IAS 16/38/20). Missing any gate field returns a validation error from ifr_batch_validate before any credit is spent. Incomplete accountingPolicy causes a hard preflight error — collect all required policy blocks upfront in one pass before step 4. Returns consolidated journal entries, trial balance grouped by XBRL section (BalanceSheet, IncomeStatement, OCI, Equity), and financial statements. SIZE CONTROL: includeWorkings (default false) and includeXbrlEnrichment (default false) both default to off for compact responses. Set includeWorkings: true to add per-item step-by-step workings and individual journalEntries (~3–10× larger). Set includeXbrlEnrichment: true to add the full xbrl metadata object on each DR/CR line (parentElement, namespace, taxonomyYear, etc.) — needed for iXBRL filing. The trial balance always carries xbrlElement, xbrlSection, xbrlLabel regardless of includeXbrlEnrichment. Pass exportXbrl: true to receive an additional xbrlFacts array — a flat list of all monetary facts with full XBRL context (element, period, currency, decimals), with {ENTITY_ID} placeholder the user replaces with their LEI or other identifier. DELIVERY TO A GOOGLE SHEET — BEFORE you call this tool, ask the user explicitly whether they want the output (the .csv journal entries AND the financial statements) delivered back into a Google table (Google Sheet), or just returned inline. If the user says yes: FIRST verify that you (the calling agent) have a working Google Sheets / Drive connector and can actually write to it — perform a real write test (create or append a throwaway cell), not just a capability assumption. If no Google Sheets connector is connected or the write test fails, tell the user and DO NOT run the batch — this call is billable and the result could not be delivered where requested; resolve the connection first. Only once the export path is confirmed: call this tool with exportJournalCsv: true, then write the returned journalCsvFile content and the financialStatements into the Google Sheet. BATCH SIZE GUIDANCE: aim for ≤50 economic events (line items) per call to stay within context window limits and receive full workings. Above 50 items the response grows rapidly; above 200 items you will very likely receive a compact response (workings and disclosures stripped, journal entries + statements + trial balance remain intact). If the user has more than 50 economic events, split into multiple calls of ≤50 items each, then merge the trial balances and journal entry lists in your context — do not attempt a single call with 200+ items unless the user explicitly accepts compact output. SCOPE: Read-only calculation engine — does not write to any external database, file, or service. Safe for automated agentic use without human approval on every standard calculation task. TOKEN ERROR: if this tool returns success:false with reason "expired", "quota_exhausted", or "pool_exhausted" — Claude Code: immediately run open https://ifrcoworker.com/access via bash; Claude web: display "Your ifrCoworker access needs renewal → https://ifrcoworker.com/access". Do not retry.. It is categorised as a Destructive tool in the IfrCoworker MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.

Register the IfrCoworker MCP server in PolicyLayer and add a rule for ifr_period_end_batch: 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 IfrCoworker. Nothing to install.

ifr_period_end_batch is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.

Yes. Add a rate_limit block to the ifr_period_end_batch 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 ifr_period_end_batch. 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.

ifr_period_end_batch is provided by the IfrCoworker MCP server (https://mcp.ifrcoworker.com). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.