It seems like each ERP promises to be the one centralized system where you can manage everything in your business. The reality is that there is no one ERP that can do everything. Comprehensive ERPs like NetSuite may be able to handle 80% of your business operations, but there will almost always be other systems involved via integrations or manual imports. It may be:
- an HR system that contains sensitive employee information and requires tighter security controls,
- a third-party logistics or warehouse partner that handles your shipping and receiving, or
- a bank, payroll provider, e-commerce platform, or another specialized application that fits your business better.
Those systems have their own processes and data, and trying to replicate it all inside the ERP doesn't always make sense. But if your ERP is the central financial system that houses all financial data, then it requires the data produced from those systems to be loaded into the ERP.
Without integration, someone usually ends up doing the work manually. Your payroll team may need to export data from the HR system and manually enter / import payroll transactions into NetSuite. Your operations team may need to manually receive purchase orders or fulfill sales orders in NetSuite to reflect what has already happened at the warehouse. At some point, the hours lost to this kind of manual work start to outweigh the cost of automating it.
But does every integration need to be real-time?
Plenty of integration options exist today. Systems provide APIs, pre-built connectors are everywhere, and platforms such as iPaaS tools can support very sophisticated integrations. All of these are great tools when the business requirement justifies them. But before building something expensive or complicated, it’s worth asking a more fundamental question first: What level of automation does the business actually need?
If you’re running an e-commerce website that takes customer orders throughout the day, you probably want those orders flowing into NetSuite quickly so the warehouse can fulfill them, and inventory counts need to move between systems often enough that customers aren’t ordering products you no longer have. That’s a case where a near-real-time API integration makes sense.
But not every business looks like that. Sometimes it’s closer to:
- Importing yesterday's expense transactions every morning
- Receiving a daily shipment confirmation from your 3PL
- Importing Amazon’s FBA (Fulfillment by Amazon) transactions once a day
- Processing a daily or weekly batch of customer, employee, or other entity data
If your business doesn't need the information immediately, building a real-time integration may be solving a problem you don't actually have. Rather than taking on the cost and complexity of building and maintaining a real-time connection the business doesn’t need, a flat-file transmission through SFTP is a practical option.
How does an SFTP integration work?
Conceptually, it’s fairly straightforward:
- The source system generates a flat file (typically a CSV or similar).
- That file moves into a secure SFTP location under your company domain.
- NetSuite connects to the SFTP server on a schedule, retrieves the file, and stores it in the NetSuite File Cabinet for automatic processing later.
A scheduled SuiteScript (NetSuite’s built-in scripting language) reads the file, validates the data, and creates or updates the appropriate NetSuite records. Depending on the needs of your business, those could be:
- Transaction Records
- Entity Records
- Custom Records
As long as the file contains the required information and there is a reliable way to identify and validate each record, this kind of automation is very achievable.
Why can this be more cost-effective?
The biggest advantage is simplicity. A real-time integration typically requires API development, authentication management, middleware licensing, endpoint monitoring, data mapping, error handling, and ongoing maintenance – and for some integrations, all of that is genuinely justified. But if you only need to move 500 transactions once a night, does it really make sense to maintain a system checking for changes every few minutes?
With an SFTP approach, the architecture can be much lighter: generate the file, transfer it, process it, and report any exceptions. NetSuite’s built-in SFTP connectivity means you can often build this process within the NetSuite environment itself, rather than introducing a separate integration platform just to move a relatively simple dataset. That keeps both the initial implementation cost and the ongoing maintenance cost low.
Simple doesn’t mean uncontrolled
A flat-file integration still needs proper controls – I would never recommend simply picking up a file and creating transactions without a plan for what happens when something goes wrong. A well-designed SFTP integration should consider:
Validation: Is the file in the expected format? Are required fields populated? Are the customers, vendors, items, subsidiaries, accounts, and other references it points to valid?
Duplicate prevention: If yesterday's file is accidentally uploaded again, the system should not create all of the transactions twice.
Error handling: One bad row shouldn't stop 999 good ones from processing. The bad row should be flagged and set aside so the automation can pick it up again once it’s fixed.
Audit trail: You should be able to determine which file was received, when it was processed, which records it created, and which records failed.
File management: Successfully processed files should be archived, and failed files or exceptions should be clearly flagged for review. Businesses that like to keep things tidy can also automate deletion of archived files after a set retention period, such as one or two years.
Notification: Someone should be alerted when a file wasn't received or when part of the integration failed.
These controls are what turn a simple file transfer into a reliable business process.
When should you use SFTP instead of an API integration?
Neither approach is better than the other – they solve different problems. If the process is high-volume, highly interconnected, customer-facing, or requires information to move instantly between systems, an API or middleware-based integration will usually make more sense. If the process is predictable, batch-oriented, and can tolerate a delay of a few hours or even a day, SFTP may be more than enough.
The right question isn't: "What is the most advanced integration we can build?"
Instead, ask: "What is the simplest reliable integration that meets the business requirement?"
Integration architecture should follow the business process — not the other way around. Sometimes that means APIs, middleware, event-driven integrations, and near-real-time synchronization. And sometimes it means a well-designed CSV file, delivered through SFTP once a day, doing the job for a fraction of the cost, does the job perfectly.
Don't underestimate the simple solution.
