Find what changed when a transaction posts wrong.
MAICA reads the NetSuite exports you already have and returns a ranked map of contributing factors across configuration and code — with the gaps named rather than hidden.
Free while in beta · No card, no NetSuite credentials
Factors, evidence, and what it could not check.
Invoice INV-10432 posted to 4010, not 4000
3 contributing factors · 1,284 records readThe income account was changed after the invoice was approved
system note · Account 4000 → 4010 · SYSTEM via SCHEDULED · 12 Jul 09:15
A scheduled process touched this field on 12 of 1,284 records
shared signature · Account / SYSTEM / SCHEDULED · 0.9% of the account
The customer's default account differs from the one that posted
saved search · no change history for this field in the export
Not checked: script deployment list and workflow definitions were not part of this upload, so anything they contributed is unaccounted for.
A script fires on a record whose configuration changed months ago. Neither specialist can see the other half.
The gap this exists to close
Four steps, no admin required.
You can try it on a real problem this afternoon, without asking anyone for permission first.
Export what you already see
A saved-search CSV and a System Notes export. Both are things a consultant can produce today — no integration record, no IT ticket, no administrator in the loop.
Handles extra columns, renamed
headers, partial date ranges, and
different formats in one upload.
Upload it, and keep the evidence
Files are normalised into one shape and stored with their provenance intact, so every later claim can point back at the exact row it came from.
Reports rows_understood
and rows_skipped, with a
reason for every skip.
Name the transaction that went wrong
You almost always arrive holding it. Type the ID and the tool gets out of the way — no dashboard to configure, no query to write.
No ID? A shortlist ranks records
by how unlike the rest of the
account they are.
Read the factors, and the gaps
Contributing factors ranked by strength of support, each with the evidence behind it, and an explicit list of what could not be checked.
A diagnostic that names its blind
spots is more trustworthy, not less.
Built for evidence you did not choose.
Real exports are partial and inconsistent. The engine is designed around that, rather than around a tidy sample.
Drag, scroll or use ← →
Two evidence types, one timeline
Saved searches and System Notes normalise into a single record shape, so a configuration change and the script that ran afterwards sit on the same clock. Nothing in the reasoning layer knows which file a row arrived in.
Ranked, not listed
Factors are ordered by strength of support, so the top of the page is where to start. Ranking uses the account's own distribution, which is what lets it work on accounts customised differently from each other.
Every claim cites its row
Each factor traces back to the exact stored record behind it, so a finding can be checked instead of trusted. The original upload is kept for the same reason.
Read-only by construction
There is no code in MAICA that writes to NetSuite. Uploads never touch your account at all, and the planned live connection requests read access only.
Evidence it reads
Dimmed sources are not ingested yet. Their real column names have not been verified against a genuine export, and guessing them would be worse than waiting.
You can already do this. That's the problem.
Every answer is somewhere in the exports already. Finding it is the part that costs an afternoon and two people.
- Scroll a change log one record at a time
- Configuration and code live in two different heads
- Whatever you did not export stays invisible
- The answer is a hunch you then have to defend
- Start from scratch on the next transaction
- One timeline across every record you uploaded
- Configuration changes and scripts ranked side by side
- Missing sources listed by name in the report
- Every factor cites the row it came from
- Ask about the next transaction in seconds
Never a single verdict.
A component touching a field does not prove it caused the outcome. Every factor carries the strength of its own evidence, in four words that always mean the same thing.
The change itself is documented in the evidence. Not a claim about cause.
Strongly supported by chronology and direct record relationships, but not proven.
Evidence exists and important gaps remain. The gaps are stated, not glossed.
No reliable conclusion available from what was uploaded. Said plainly.
We cannot modify anything in your account.
True by construction, not by policy. It is the strongest sentence available in a security conversation with a client running production finance, so the product is built to keep it true.
Read-only, always. Nothing is ever written to a client ledger.
Start with file upload — nothing connects to your NetSuite account.
Sign in with Google. We never ask for a NetSuite password or token.
Each client account is isolated, and every read is authorised.
Every factor traces back to the stored row it came from.
When a source is missing, the report says so instead of guessing.
What people ask first.
Does MAICA connect to my NetSuite account?
Not today. You upload exports you generate yourself, so nothing touches your account and no administrator has to approve anything. A live read-only connection is planned as an upgrade for people who already want it, never as a requirement to start.
Can it change anything in my account?
No, and not as a matter of policy. There is no code in MAICA that writes to NetSuite. Even the planned live connection is read-only, requesting no permission the analysis does not use.
What exactly do I upload?
A saved-search CSV of the transactions you care about, and a System Notes export covering the same period. Both are things a consultant can already produce without special rights.
Extra columns, renamed headers and partial date ranges are all fine. MAICA reports how many rows it understood and how many it skipped, and why.
Will it tell me the root cause?
Deliberately not. It returns contributing factors ranked by the strength of their evidence, and you decide. A script touching a field does not prove it caused the outcome, and a tool that says otherwise is guessing with confidence.
What happens to my client's data?
It is stored so the analysis can cite it, isolated per client account, and treated as confidential regardless of what it contains. You can delete a client account and everything uploaded under it at any time.
The details are in the privacy policy.
Who is it for?
NetSuite consultants — functional and technical — and the administrators and controllers who feel the pain when a transaction posts wrong. It is built for the gap between the two specialisms, so it is most useful when neither person can see the whole picture alone.
What does it cost?
Nothing during the beta. Pricing is not settled, and when it is, it will be aimed at the client or the consulting firm rather than at the individual consultant — the person who saves the time is rarely the person who captures the benefit.
How far along is it?
Beta, and honest about it. Upload, normalisation, the dependency graph, the ranking and the report all work end to end. The live NetSuite connection does not exist yet, and some evidence types are not ingested because their real column names have not been verified against a genuine export.
Bring it the one that posted wrong. Upload a saved search and a System Notes export, and see what the account has to say about it.
Free while in beta · About five minutes end to end