Most NetSuite problems are design decisions nobody noticed.
I'm John. I work in NetSuite for a living and write about what I see: how systems of record should be designed*, where automation quietly goes wrong, and the why behind the fix. These are the notes.
* in my opinion. that's the whole site.
What I keep coming back to
A few positions show up again and again across the notes. Most of what I write is some version of one of these.
Feed the engine, don't fake the result
Most "automation" computes the answer upstream and posts a number the system can't explain. I write a lot about keeping logic inside the system of record, where it can be reported, audited, and trusted.
Read the note →Decide before you map
Field maps don't prevent misposts; unowned decisions do. I keep returning to the idea that integrations and tax and reporting all break at the same place: nobody owns the classification.
Read the note →A control plane, not a pile of scripts
If execution depends on someone's laptop, you don't have a system. The thread through a lot of these notes: build things that are observable, transferable, and governable, or don't build them.
Read the note →The biases behind the writing
If you read enough of the notes, the same handful of convictions keep surfacing. These are them.
Why before what
Most "missing line" and "broken report" problems aren't data errors. They're design decisions made without anyone noticing. I try to write about the cause, not the symptom.
Record, not reason
The system of record is valuable because it preserves context: what happened, why, and how it should be reported. Strip that out and you're storing outcomes you'll pay to reverse-engineer later.
Knowing when not to build
Fewer scripts, not more. Configuration over customization. The most useful thing I can tell a team is often what to leave alone.
You might recognize some of this
The notes tend to land for people living inside a NetSuite environment that grew faster than anyone documented. A few of the situations they come from:
- You inherited a NetSuite environment and you're not sure what's safe to touch
- Automation that "works" but nobody can explain when an auditor asks
- Reports built around hand-picked accounts that quietly break
- A pile of customizations where nobody remembers the original decision
- You want the why behind a recommendation, not just the click path
The latest notes
This is the actual point of the site. What I'm seeing, fixing, and arguing about across NetSuite environments.
- N01
E-Invoicing Infrastructure That Holds Up
A practical walkthrough of e-invoicing infrastructure, NetSuite integration, AP automation, country scoping, and implementation pricing.
- N02
Ten Questions Before You Automate
A practical method for understanding triggers, inputs, decisions, exceptions, and outputs before building reliable automation.
- N03
Automation Requires System Knowledge
Automated intelligence depends less on tools than on clear systems, known data structures, and repeatable operational decisions.
If this is how you want your systems run
There's no funnel here. Read the notes, and if the way I think about this work fits what you're dealing with, the door is open. We can talk.