When a growing organic grocery retailer found itself running NetSuite with manual tax entries, brittle approval workflows, and a few too many “wait, why is this still here?” scripts, Salora ERP stepped in to help clean things up.
Background
Our client is a multi-location natural and organic grocery chain that had already been running NetSuite for some time before engaging Salora ERP.
They were not in crisis. The stores were open. Transactions were moving. The finance team was getting through the day. Procurement was doing procurement things. Inventory was inventorying.
But NetSuite has a funny way of looking “fine” on the surface while quietly collecting technical debt in the background like a junk drawer full of old chargers.
Workflows had been built quickly and never revisited. Taxes were being entered manually every day through Journal Entries. Custom scripts were running in production without much documentation. Employee access records for people who had already left the company were still tangled into approval conditions. And every now and then, some edge-case transaction would come through, like an EDI purchase order or a vendor bill stuck in approval, and the team would be left asking the classic NetSuite question:
“Okay, but why?”
They did not need someone to just patch one issue and disappear. They needed a partner who could look at the whole environment, identify the real risks, prioritize what mattered, and then actually build the fixes.
The Health Check
We started with a comprehensive Health Check of their NetSuite environment.
Not a “click around for an hour and send over three bullet points” kind of audit. This was a proper look across Accounting, Procurement, Inventory, Workflows, Security, and the surrounding operational processes.
Basically, we wanted to know:
- What is working?
- What is technically working but held together with tape?
- What is creating risk?
- What is wasting time?
And what is one weird workflow condition away from ruining someone’s Wednesday?
The Health Check gave us a prioritized list of findings tied directly to operational risk and real business impact.
Here is what we found:
Taxation: Manual Journal Entries, Every Day
The client’s team was recording all taxes manually through Journal Entries on a daily basis.
To be fair, this is one of those processes that can feel harmless at first. Someone knows the routine. The numbers get entered. The report gets updated. The day moves on. Until you zoom out.
Manual daily tax entries introduce a lot of risk. Human error can creep in. Audit trails get messier than they need to be. Tax liability reporting becomes harder to trust in real time. And the finance team spends time doing something NetSuite can already help automate.
It reminded us of a previous cleanup we saw years back, where the process technically “worked” because one very patient person knew exactly how to do it. Which is great, until that person goes on PTO and suddenly the entire process becomes tribal knowledge wearing a cardigan.
Our recommendation was straightforward: enable NetSuite’s Advanced Taxes feature and eliminate the manual tax entry process.
Setup → Company → Enable Features → Tax subtab → Advanced Taxes → Save
With native automated tax computation, the client could reduce daily manual work, produce cleaner and more auditable records, and reduce the risk of tax misclassification.
We documented the recommendation, laid out the implementation guidance, and flagged it as a high-priority item for leadership to review and approve.
Approval Workflows: Hardcoded and Fragile
The approval workflows for Journal Entries, Vendor Bills, and Purchase Orders all had the same structural issue:
Approver names were hardcoded directly into the workflow conditions.
That meant every time someone changed roles, left the company, or needed to be added as an approver, someone had to go into the workflow itself and manually update the condition.
Which is not ideal.
Hardcoding approvers into workflow logic is a bit like writing your grocery list in permanent marker on your kitchen wall. It works until something changes, and then suddenly you are remodeling the wall because you ran out of eggs.
In this case, we found evidence of an employee whose access had been toggled on and off multiple times across a six-month period. Not because that was the intended design, but because the workflow required manual maintenance and there was no clean process for keeping it updated.
Our recommendation was to redesign the approval logic around checkbox fields on the Employee record.
(can’t show the screenshot for this, proprietary information there! Hehe)
For example, instead of embedding a person’s name directly into the Journal Entry approval workflow, the employee record could include a field like “Journal Entry Approver.” If someone needs to be added or removed from the approval chain, the client updates one field on the employee profile.
No workflow surgery required.
The result is cleaner, more dynamic, more auditable, and much easier to maintain.
Purchase Order Workflow: Gaps in Logic
The Purchase Order approval workflow had two specific issues.
First, certain users from key internal teams were not reflected in the Approve and Reject button conditions. That meant POs could reach approval steps without the right people properly included in the process.
Second, a category of direct-ship purchase orders was supposed to auto-approve, but the condition was not written tightly enough to catch all of the right cases. As a result, some POs were getting stuck in pending status even though they should have moved through automatically.
This is one of those NetSuite problems that can make everyone feel a little haunted.
The workflow is active. The rules look reasonable. The button is there. The status says pending. Everyone insists they did their part. And still, the transaction just sits there like a car with the parking brake on.
Both issues were identified, documented, and queued for resolution as part of the broader workflow overhaul.
What We Built
Once the Health Check gave everyone a clear picture of the environment, we moved into execution.
The goal was not to create more complexity. The goal was to remove fragility, reduce manual work, and make the system easier for the client’s team to manage going forward.
Approval Workflow Overhaul
The workflow redesign became the largest single piece of work to come out of the Health Check.
We rebuilt the Journal Entry, Vendor Bill, and Purchase Order approval workflows from the ground up, replacing hardcoded approver conditions with dynamic, role-based logic tied to employee record attributes.
The PO workflow also received targeted updates to close the logic gaps identified during the audit. We added the missing user conditions to the Approve and Reject buttons, then tightened the auto-approval condition for direct-ship orders so it would fire reliably.
All changes were built and tested in sandbox before deployment to production. Documentation was also provided so the client’s team could understand what changed, why it changed, and how to maintain it moving forward.
A lot of ERP cleanup work fails because the fix is technically correct but impossible for the internal team to understand later. We do not want clients needing a flashlight, a detective board, and three former consultants just to figure out why a workflow works.
Automatic Inventory Adjustment on Item Receipt
One of the more painful operational processes involved creating Inventory Adjustment records manually after every Item Receipt involving header-linked items.
Every receipt required a follow-up step:
- Open the receipt.
- Identify the item.
- Create the adjustment.
- Link it back.
- Repeat.
It was the kind of process that makes sense for about five minutes, then becomes the thing everyone quietly hates by week three.
So we automated it.
We built a User Event Script that creates the corresponding Inventory Adjustment automatically when an Item Receipt is created and the item has a Header Item set on the item record.
The script also links the Item Receipt and Inventory Adjustment to each other through System Information, giving the client a cleaner record trail.
We also added a configurable parameter for the default Inventory Adjustment account, which means the finance team can update the account mapping without needing to touch the script itself.
The prerequisite is simple: the item needs to have the Item Header field populated.
If that field is blank, the script does not fire. Predictable. Controlled. Easy to understand.
That is the sweet spot.
CSV Import Suitelet for Purchase Contracts
The client’s procurement team was managing Purchase Contract records through manual data entry.
For a multi-location retailer with their level of volume, that was a significant time drain. It also created room for inconsistent contract data, which is exactly the kind of small issue that eventually turns into a reporting problem, then a process problem, then a “who owns this?” problem.
We built a SuiteScript-based Suitelet that allows the team to create and edit Purchase Contract records through CSV import.
Instead of entering records one by one, the procurement team now has a controlled, repeatable import process that reduces manual effort and improves data consistency.
It is not the flashiest customization in the world, but these are the fixes that save teams real time.
Not every hero wears a cape. Some just upload a CSV properly.
Item Filtering on the Purchase Order Sublist
When users built Purchase Orders, the item sublist showed the full item catalog. All of it. Even items that were not relevant or approved for purchasing.
That kind of open-ended selection may seem harmless, but in procurement, too many choices can create risk. If a user can select the wrong item, eventually someone will select the wrong item. NetSuite users, like all software users, are still human beings. Sometimes they are also under-caffeinated.
We built a customization that filters the available items on the PO item sublist based on the right context.
That means users now see only the items that are appropriate for that purchasing scenario, reducing the risk of incorrect items being ordered and tightening the overall procurement process.
Vendor Bill Auto-Approve Logic and Stuck Bills
The team was also seeing vendor bills pile up in pending approval status without a clear path forward.
Some were stuck because workflow conditions had not been updated to reflect the current approval structure. Others were hitting edge cases that the original workflow logic had never accounted for.
This was one of those issues where the symptoms were obvious, but the cause lived in the details.
The bills were there. The approvals were not moving. The team knew something was wrong.
But the system was not exactly raising its hand and saying, “Hi, I am stuck because of line 4 of this workflow condition.”
We implemented auto-approve logic for vendor bills that met defined criteria, clearing the backlog and reducing the ongoing volume of manual approvals required.
This fix was part of the broader workflow overhaul, but it was scoped and deployed specifically to address the billing bottleneck.
EDI Purchase Order: Bill in Advance of Receipt
One of the more interesting edge cases involved a specific purchase order from one of the client’s produce vendors.
The PO came through flagged as an EDI order. The existing workflow used the EDI flag as a condition to remove the Receive button. That meant the PO was approved, but it could not be received. And because it could not be received, it could not be billed.
Very fun. Very normal. Very NetSuite.
The root cause was clear once we found it: the workflow condition was doing what it had been told to do, but it was not accounting for cases where an EDI-flagged PO still needed to move through the standard receiving and billing flow.
The “Bill in Advance of Receipt” feature was also not enabled on the account, which meant the alternative path was unavailable.
Instead of enabling Bill in Advance of Receipt globally, which would have affected all orders going forward and required the client to review downstream impact, we created a targeted exception for the specific order.
That allowed the PO to move through receipt and billing without changing the system-wide behavior.
We also documented the tradeoffs clearly so the client could make an informed decision about whether enabling the feature globally made sense in the future.
That is an important part of this kind of work. Sometimes the answer is not “turn on the feature.” Sometimes the answer is “let’s solve the immediate problem without creating twelve new ones.”
Landed Cost Setup and Training
Separate from the Health Check work, the client also needed a walkthrough of NetSuite’s Landed Cost capabilities.
They were evaluating both native Landed Cost functionality and the Estimated Landed Cost feature from the SCM bundle. Before committing to a setup approach, they needed to understand how each option applied to their procurement scenarios.
We ran a full demo session covering:
- Header Landed Cost
- Line Landed Cost
- Estimated Landed Cost
- The Landed Cost Bill flow
We used purpose-built test purchase orders and test items for the session, because nothing makes NetSuite training go sideways faster than trying to demo a concept with messy sample data and a prayer.
We also prepared a detailed user guide covering both the native and SCM bundle approaches, giving the client’s team a reference document they could return to after the session.
What Is Still in Motion
The engagement is ongoing.
Recently, the finance team requested an enhancement to their Period Performance Reports. Specifically, they wanted to add a COGS-as-a-percentage-of-Sales calculation broken out by department within each store, for both the Period view and the YTD view.
That is a meaningful reporting improvement. It gives leadership better visibility into store and department-level performance, and we are currently scoping and quoting the work.
There is also an active technical review underway on the NetSuite SQL side, along with a recently completed project around automating pending approval list email notifications to reduce delays in the approval cycle.
In other words: the cleanup work did not end with the first set of fixes. It created a better foundation for continuous improvement.
The Bigger Picture
This engagement is not unusual.
A lot of companies running NetSuite have already done the hard part: they got live. The implementation happened. The system works. The team knows how to get through the month. But over time, things accumulate.
Workflows that made sense at go-live stop matching how the business actually operates. Manual workarounds become standard operating procedure. Scripts get deployed and never documented. Former employees stay embedded in approval logic like ghosts in the machine.
None of it feels urgent.
Until
- a PO will not receive.
- Or a vendor bill will not approve.
- Or someone asks whether the tax numbers are fully reliable.
- Or leadership wants better reporting and everyone realizes the underlying setup is not as clean as it needs to be.
That is why the Health Check mattered.
It was not about finding problems for the sake of finding problems. It was about giving the client a clear picture of how their NetSuite environment actually worked, where the risks were, and what needed to be prioritized.
From there, the work becomes practical:
Find the highest-leverage issues. THEN Fix them properly. THEN (importanmtly) Test in sandbox. THEN Deploy carefully. THEN Document what changed.
Hand the system back in a state the client can actually maintain.
That is the real work.
Not glamorous, maybe. But very useful. And in NetSuite, useful beats glamorous almost every time.
If your NetSuite environment has been running for more than a year and no one has done a systematic review, there is probably something in there worth finding.
Reach out. We are happy to take a look.
Again, the Free Healthcheck thing. Ehem ehem.
