Netsuite

SuiteQL is available to your assistant, which means an ad hoc SQL query against your NetSuite data with server-side paging, without anyone building a saved search first. It can also list and run the SuiteAnalytics datasets your team has already built, so an existing workbook becomes something you can ask about in conversation. Both routes read; neither writes.

What you end up with. An answer to a specific question about your own data, with the query it ran shown so somebody can check the logic.

Start with it bringing you the information and you deciding.

Never without. Read the query, not just the number. A SuiteQL result is only as good as its joins and its subsidiary filter, and a total that quietly covers one subsidiary looks identical to one that covers the group.

Built on: Run SuiteQL Query / List Datasets / Execute Dataset / List Records

The assistant can list invoices with filters and paging, open the ones that matter for the full detail, and read the customer payments already recorded against them. That is the receivables position assembled from the records rather than from a report someone exported last week, and it can group it by customer or by age however you ask.

What you end up with. An aged list of open invoices by customer, with payments already applied taken into account and the total stated.

Start with it bringing you the information and you deciding.

Never without. Have it say how many records it read and whether it reached the end of the pages. These listings are paginated, and receivables assembled from a first page understate the position without ever looking wrong.

Built on: List Invoices / Get Invoice / List Customer Payments / Get Customer

Purchase orders, item receipts and item fulfillments are all readable, so the assistant can trace an order from what was placed to what was received to what went out again. Reading a purchase order returns the vendor, the line items, the amounts, the dates and the status in one call, which is the part that usually takes three screens.

What you end up with. A per-order trace showing what was ordered, what has been received against it, and what is still outstanding.

Start with it bringing you the information and you deciding.

Never without. Treat a missing receipt as a missing record rather than a missing delivery. Goods that arrived and were never receipted in NetSuite are invisible here, and that gap is a process finding rather than a logistics one.

Built on: List Purchase Orders / Get Purchase Order / List Item Receipts / Get Item Receipt / List Item Fulfillments

NetSuite exposes its own schema, so before writing anything the assistant can pull the full metadata for a record type: every field, its data type, its constraints, and whether it is required, including custom fields your account added. It can also follow a select field such as subsidiary or currency through to the record it points at, and read the lines of a sublist. This is how an assistant stops guessing at a NetSuite record shape.

What you end up with. The actual required and optional fields for the record type in your account, custom fields included, before anyone tries to create one.

Start with it bringing you the information and you deciding.

Never without. Ask for this before any create or update rather than after the first failure. The metadata is account specific, and an assistant that skips it will produce a body that is valid NetSuite and wrong for your configuration.

Built on: Get Record Metadata / List Metadata Catalog / Get Reference Select Field / Get Sublist Collection

NetSuite has a transform operation that creates one record from another and carries the data across, which is how a sales order becomes an invoice or a purchase order becomes an item receipt. The assistant can read the source order first, run the transform, then read the new record back to confirm what actually landed on it. It is a create, so the source record stays where it is.

What you end up with. A new invoice populated from the sales order, read back and confirmed, with the source order untouched.

Start with it doing the work and checking with you.

Never without. Read the resulting record before anyone acts on it. A transform carries lines, dates, terms and taxes across on NetSuite's rules rather than yours, and the differences show up on the customer's copy.

Built on: Get Sales Order / Transform Record / Get Invoice / Update Invoice

The assistant can create the vendor record, which needs the company name and a subsidiary, and then create the bill against it with its line items. Both return the created record's location so it can read them back and quote you the internal IDs. For a large account it can run these asynchronously and poll the job rather than holding a long request open.

What you end up with. A vendor record and a matching vendor bill in NetSuite, both read back with their internal IDs, ready for approval.

Start with it doing the work and checking with you.

Never without. Check for an existing vendor before it creates one, and confirm the subsidiary yourself. Duplicate vendor records are the standard way an accounts payable ledger goes wrong, and the subsidiary decides which set of books the bill lands in.

Built on: Create Vendor / Create Vendor Bill / Get Vendor / Get Vendor Bill / Get Async Job Status

There is an upsert that works on your external ID, so the assistant can create the record if it is new and update it if it is not, in one call, without first working out which case it is in. Updates use patch semantics: only the fields you name change and everything else stays as it was. That combination is what makes a repeated sync safe to run rather than a source of duplicates.

What you end up with. NetSuite customer records that match the source system, matched on your own external ID rather than on name, with untouched fields left alone.

Start with it doing the work and checking with you.

Never without. Fix the external ID convention before the first run and check a sample record afterwards. An upsert keyed on an ID that does not match creates a second customer instead of updating the first, and it does that quietly, once per run.

Built on: Upsert Record by External ID / Update Customer / Get Customer / Get Record Metadata

Journal entries, invoices and sales orders can all be deleted by ID. NetSuite's connector is direct about what that means and there is no trash to fish it back out of. It is worth saying that in accounting a deletion is usually the wrong instrument in the first place: a reversing entry keeps the audit trail, and a deleted journal entry does not.

What you end up with. A copy of the record's full contents saved outside NetSuite, and either the deletion you approved or the reversing entry you decided on instead.

Start with it doing the work and checking with you.

Never without. Approve the exact internal ID, have it read and save the record contents first, and check the accounting period is still open. Deleting a posted journal entry removes it from the general ledger with no undo, and doing it in a closed period is an audit problem rather than a data one.

Built on: Get Journal Entry / List Journal Entries / Delete Journal Entry / Delete Invoice / Delete Sales Order