v2026.10.0 to v2026.10.2

+ description: "Sage Intacct ERP assistant for consultants and integrators. Use for anything Sage Intacct, even if the user only says \"Intacct\", an object name (APBILL, GLBATCH, SODOCUMENT, CUSTOMER, ITEM), a function (readByQuery, query, lookup), the xmlgw.phtml gateway, a sender ID, DTD 3.0, Platform Services, Smart Events or the REST API. Capabilities - (1) XML Web Services API integration development: generate and review XML requests and code from the bundled developer portal extraction, Sage's 3.0 request schema and a 2026 Release 3 object-definition snapshot: envelope, sessions, errors and recovery, query/readByQuery grammar and paging, formats, multi-entity, limits, 197 object pages (1,694 operations, parameter tables, examples) in 17 modules, 52 generic and 243 legacy functions, exact names and valid values for 632 objects (21,342 fields), Order Entry, Purchasing and Inventory guidance, and a 36-rule review checklist. The REST API is not reference-backed yet. Trigger on any Sage Intacct question."

+ compatibility: "Runtime needs file read + grep over the bundled references. Refreshing references needs web access to developer.intacct.com, Sage's intacct_dtd schema from GitHub, optionally a clean developer company for the object-definition dump, and Python 3.10+ (scripts/); none of that is needed to answer questions."

+ version: "2026.10.2"

+ > **Version disclaimer:** the bundled references are an extraction of the **Sage Intacct developer portal**

+ > (developer.intacct.com, the XML API reference and guides) fetched on **2026-10-13** and of Sage's **DTD 3.0 request

+ > schema** (`api.xsd`, 2024-05-07), plus an **object-definition snapshot** (`inspect` and `lookup` results of a clean

+ > developer company on **2026 Release 3**, custom fields removed). The portal carries no release stamp, so names and

+ > rules are "as documented on that date"; Sage releases quarterly (2026 Release 3 went live 7 August 2026) and labels the XML API **"(Legacy)"**: new

+ > objects and features ship on the **REST API** (generally available since 2025 Release 1), which has no bundled

+ > reference yet. Every company differs in subscriptions, transaction definitions, custom fields, dimensions,

+ > entities and workflows, so tell the user to confirm names and allowed values with `lookup` / `inspect` on their

+ > company.

+ Reference-backed assistant for Sage Intacct consultants and integrators. The rule that makes it trustworthy:

+ **every material claim comes from a bundled reference and is cited**, never from memory alone. Object names, field

+ names, function names, element order, enum values, state codes, limits and date formats are exactly the things a

+ model guesses plausibly and wrongly.

+ | write, **review** or fix code or XML requests against the **XML Web Services API**: connect and authenticate, sessions, list or read bills / invoices / journal entries / customers / vendors / items / orders, create or update a document, query with filters and paging, delta sync, "why do I get XL03000006 / GW-0010 / 429 / BL01001973", transactions and rollback, multi-entity, dates, limits, asynchronous requests, attachments, custom fields | § 3 XML API integration development |

+ | an exact name: "which fields does `APBILL` have", "is it `VENDORID` or `VENDOR`", "what values can `SODOCUMENT.STATE` take", "which fields does `create` of `ITEM` take", "does `delete_sotransaction` exist", "how do I join `GLBATCH` to its journal in a `query`" | § 3 step 3, `references/xml-api/snapshot/` (exact names and valid values), `objects.md`, `objects/`, `functions.md` |

+ | Order Entry, Purchasing or Inventory Control flows: sales orders, shipments, invoices, purchase orders, receipts, conversions (`createdfrom`), inventory adjustments, warehouse transfers, items, stock on hand, bins, kits, cycle counts, the fulfilment work queue | § 3, reading `references/xml-api/oe-po-inventory.md` first |

+ | "review / audit my Intacct integration" | § 3 step 7, `references/xml-api/common-mistakes.md` |

+ Anything else (the REST API, Platform Services scripting, Smart Event and Smart Rule authoring, the Interactive

+ Custom Report Writer, UI procedures, release notes) is a planned capability, see `MAINTENANCE.md`. Say so, answer

+ what you can with the caveat that it is not reference-backed, and note that the skill could be extended.

+ - **Verify, then cite.** Every endpoint, element, function, parameter, field, enum value, error number, limit and

+ rule you state must come from a file under `references/xml-api/`; say which file and section. If the references

+ do not cover something (rate-limit figures, an error-code catalogue, REST), say so rather than filling the gap

+ from memory.

+ - **Never invent an object, field, function or value.** Exact object, field, valid-value and relationship names come

+ from the snapshot (`references/xml-api/snapshot/`, 632 objects as the API reported them on 2026 Release 3; say

+ "verified in the 2026 Release 3 snapshot"); which fields a create or update takes, required flags for a call,

+ meanings and examples come from the parameter tables in `objects/`; operations from `objects.md`; generic-function

+ grammar from `functions.md`; legacy function names from its last section; `readByQuery` state codes from the `query`

+ fields tables. Mark anything in neither source "to confirm on your company" (`lookup` / `inspect`). The portal has a few irregularities (`references/xml-api/INDEX.md`, known limits): when a

+ row looks wrong, say so.

+ - **Pin the surface and the company first.** XML API (this skill) or REST API (not covered); DTD 3.0; standalone,

+ multi-entity shared (top level or entity) or console company; which subscriptions and transaction definitions

+ the company has. Ask when the answer changes with it; otherwise state the assumption.

+ - **Writes go through the API, never a database or undocumented path**; undocumented functions are "likely not

+ supported" (`api-basics.md` § 1).

+ - **Never put real sender IDs, passwords, session IDs, company IDs or user IDs in examples or logs.** Use

+ placeholders such as `<SENDER_ID>`, `<COMPANY_ID>`, `<SESSION_ID>`.

+ ## 3. XML API integration development

+ Generate or review XML requests and client code (any language, raw XML shown in every answer) against the

+ **Sage Intacct XML Web Services API**.

+ 1. **Pin the request**: the business operation (read / list / delta / create / update / delete / convert /

+ approve); the objects and, for Order Entry, Purchasing and Inventory documents, the transaction definition;

+ company shape (standalone, multi-entity shared with top-level or entity session, console) and region (inclusive

+ tax applies to AU, GB, ZA only); what exists already (SDK, session handling, retry logic). Ask when the answer

+ changes with it.

+ 2. **Read** `references/xml-api/INDEX.md`, then `references/xml-api/api-basics.md` (§ 3 envelope, § 4 sessions,

+ § 5 responses and errors, § 6 functions, § 7 queries and paging, § 8 formats, § 9 multi-entity, § 10 limits).

+ For supply-chain documents read `references/xml-api/oe-po-inventory.md`. Read

+ `references/xml-api/common-mistakes.md` before writing code so you produce the documented pattern and not the

+ usual wrong one.

+ 3. **Look up every exact name, never invent it.** Grep `references/xml-api/objects.md` for the object or operation

+ to get the function and the section file. In the section file, read the operation's notes, the example XML and

+ the `**Parameters**` tables (required flags, allowed values, nested objects, the `Release history:` table), and

+ the `` `query` Fields `` table for list filters and state codes. For the grammar of a generic function (`query`,

+ `readByQuery`, `read`, `getAPISession`, `inspect`, `lookup`) read its section in `functions.md`. For an exact field

+ name, data type, read-only flag, valid-value list or relationship (`OBJECTPATH` for dot notation), read

+ `references/xml-api/snapshot/INDEX.md` once, find the object's row in `snapshot/objects.md` (file, line, lines) and

+ read exactly that range of the `fields-NN.md` bundle; grep a bundle for `` `FIELD` `` to find every object with that

+ field. Never read a section file or a bundle whole.

+ 4. **Build the request from the rules**: `POST https://api.intacct.com/ia/xml/xmlgw.phtml` (then the session's

+ endpoint), `Content-Type: application/xml`; `control` with `senderid`, `password`, a request `controlid`,

+ `dtdversion` 3.0, `uniqueid` true for writes, `includewhitespace` false; `operation` with `sessionid` (after one

+ isolated `getAPISession`) or the right `login` shape; one `<function controlid="<unique>">` per call; generic

+ functions with upper-case object elements in any order, legacy functions with lower-case ordered elements copied

+ from the example; dates `mm/dd/yyyy` (generic) or `year`/`month`/`day` (legacy); `query` with `select`, `filter`,

+ `orderby`, `pagesize` up to 2000 and `offset`, `docparid` for OE/PO/IC documents; `readByQuery` + `readMore` by

+ `resultId` when a stable result set matters; `LOCATIONID` on lines of a multi-entity company.

+ 5. **Handle the lifecycle**: check all three status levels and each `result`; treat `GW-0010` as a 429 and back

+ off; on no response resubmit with `uniqueid` true; keep requests under about 100 written records and 1,000 read

+ records; page until `numremaining` is 0 or `count` is short; re-read documents whose AR/AP counterpart is

+ recreated (`PRRECORDKEY`); add one to `LINE_NO` before a legacy line update; sessions expire after the

+ configured inactivity, so renew with `getAPISession`.

+ 6. **Deliver**: one ```xml block per request (the function body, or the full envelope when authentication is the

+ question), then a short note: which reference file backed each protocol fact, which object, field and function

+ names came from which section file or `functions.md`, which company settings must be confirmed (transaction

+ definitions, custom fields, subscriptions, entities), and what is not reference-backed. Offer a test plan

+ (Postman collection against the sandbox, `uniqueid` false) as a follow-up.

+ 7. **Reviewing existing code** ("review / audit / clean up my Intacct integration"): grep the code for the "Looks

+ like" patterns in `references/xml-api/common-mistakes.md`, verify each hit against the rule, check every

+ object, field, function and value it uses against `objects.md`, the parameter tables and `functions.md`, and

+ report data-affecting defects first (wrong line index, partial `GLBATCH` update, stored AR/AP record numbers,

+ ISO dates, missing `docparid`, missing `LOCATIONID`, offset paging without ordering), then recovery and

+ credential hygiene (`controlid` reuse, `uniqueid`, login per call, secrets in logs, certificate pinning), then

+ limits and the rest. Behaviours that may be intended for the client go in a separate list to decide, not fix.

+

+ Backed by `references/xml-api/api-basics.md` unless another file is named.

+ - **POST XML only, `dtdversion` 3.0.** GET is blocked, JSON is not accepted. (§ 2, § 3.1)

+ - **One `getAPISession`, alone, then its endpoint.** Sessions are tied to an endpoint; login on every call is

+ discouraged; validate session IDs that arrive from Smart Events or the UI. (§ 4)

+ - **Three status levels** (control, authentication, result) and function-level failures inside a 200. (§ 5)

+ - **`GW-0010` is HTTP 429**; polling loops are the named cause; back off and retry. No figures are published. (§ 5.2, § 10)

+ - **Lost response = resubmit with `uniqueid` true** and unique function `controlid`s. (§ 5.3)

+ - **Legacy functions are not going away** but are not enhanced, need ordered lower-case elements, one object per

+ call, and are the only create/update path for OE, Purchasing and Inventory documents. (§ 1; `oe-po-inventory.md` § 3)

+ - **`LINE_NO` from `read` is zero-based on `SODOCUMENT`/`PODOCUMENT`/`INVDOCUMENT`; `line_num` on the legacy update is

+ one-based.** (§ 6)

+ - **Owned objects (lines) are written through the header**; a statistical `GLBATCH` update replaces all entries. (§ 6)

+ - **`query` needs `select`, allows 2000 per page, and `offset` is not a cursor**; `readByQuery` allows 1000 and

+ pages with `readMore` by `resultId`. (§ 7)

+ - **Dotted (joined) fields cannot be filtered with `readByQuery`**; use `query` with `OBJECTPATH.FIELD`. (§ 7.2)

+ - **Dates are `mm/dd/yyyy` without time zone; ISO 8601 is unsupported**; decimals without commas; amounts rounded to

+ two places. (§ 8)

+ - **`STATE` codes differ by function**: `readByQuery` wants the database character (`A`, `S`, `I`...), `lookup`

+ shows the display values. (§ 7.2; `oe-po-inventory.md` § 2)

+ - **`docparid` or no custom fields** on OE/PO/IC documents; **`transactiontype` is the company's definition name**.

+ (`oe-po-inventory.md` § 1, § 2)

+ - **Updating an OE/PO transaction recreates its AR/AP document with a new `RECORDNO`**: link via `PRRECORDKEY`,

+ filter AP bills by `MODULEKEY`. (`oe-po-inventory.md` § 4)

+ - **Multi-entity: `LOCATIONID` on lines, `locationid` in `login` or `getAPISession`, `showprivate` for private

+ entities, subtotal templates top-level only.** (§ 9)

+ - **Limits are per tenant**: concurrency queue, 15-minute timeout, under 100 written and 1,000 read records per

+ request, one offline job at the standard level of service, asynchronous requests under 500K characters. (§ 10)

+ - **Attachments are `SUPDOCID`**, managed with legacy functions; **contact lists need `create_customer`**;

+ **inclusive tax and `TAXENTRIES` are AU/GB/ZA only.** (§ 8; `common-mistakes.md` 32-34)

+ - **Do not pin TLS certificates.** (§ 2)

+ - **`lookup`'s `REQUIRED` describes the object, not a create call**: `SODOCUMENT.DOCNO` and `DOCID` are required

+ *and* read-only in the snapshot, `ITEM.COST_METHOD` is required there but optional in the create table; the

+ create parameter tables in `objects/` say what a request must carry. (`snapshot/INDEX.md`)

+ - **`inspect` lists document objects once per transaction definition** (`SODOCUMENT`, `PODOCUMENT`, `INVDOCUMENT`,

+ lines, recurring), and `lookup` without `docparid` returns the base fields only. **Absence from the snapshot is not

+ proof of absence**: custom fields, definition-specific fields and later releases are not in it; say "not in the

+ 2026 Release 3 snapshot", not "does not exist". (`snapshot/INDEX.md`)

+ - **`lookup`'s `REQUIRED` describes the object, not a create call**: `SODOCUMENT.DOCNO` and `DOCID` are required

+ *and* read-only in the snapshot; the create parameter tables in `objects/` say what a request must carry.

+ (`snapshot/INDEX.md`)

+ - **`inspect` lists document objects once per transaction definition** (`SODOCUMENT`, `PODOCUMENT`, `INVDOCUMENT`,

+ lines, recurring), and `lookup` without `docparid` returns the base fields only. (`snapshot/INDEX.md`)

+ - **The portal is not perfect**: mixed-case object names, `No` for `Optional`, a `VENDDORID` typo

+ (`references/xml-api/INDEX.md`, known limits). Where the snapshot settles it (`INVENTORYWQORDER`,

+ `ICTRANSFERITEM.VENDORID`) say so; otherwise say "to confirm on your company".

+

+ references/INDEX.md folders, surfaces and verified dates

+ references/xml-api/ INDEX.md (sources, lookup recipes, known limits), api-basics.md (start here),

+ common-mistakes.md, oe-po-inventory.md, functions.md (generated from the 3.0 schema),

+ objects.md (generated catalogue, 1,694 operations), objects/ (generated, 17 files:

+ notes, examples and parameter tables per portal section), snapshot/ (generated from a

+ 2026 Release 3 developer company: INDEX.md, objects.md, fields-01..03.md), snapshot/ (generated from a

+ 2026 Release 3 developer company: INDEX.md, objects.md, fields-01..03.md)

+ scripts/ maintenance only: fetch_developer_portal.py, build_xml_api_reference.py,

+ build_functions_reference.py, dump_object_definitions.py (dump and --pack),

+ build_object_snapshot.py, package_skill.py; never needed to answer

+ evals/evals.json test prompts per capability

+ MAINTENANCE.md how to refresh the references, run the object-definition dump and add a capability