100 Reasons Why Carillon® ERP
Is Better Than NetSuite®

Language in an ERP system is about more than geography. It's about how your business describes itself. If your company calls them clients instead of customers, donors instead of accounts, or members instead of contacts, your software should reflect that - not force your people to mentally translate Oracle's terminology into yours every time they open a screen.

Carillon's multilingual functionality is built around that reality. Three users sitting side by side can each work in a different language simultaneously - English, Spanish, French, or any other - without any conflict or configuration gymnastics. And if none of the standard languages fit, you can build your own. More practically, you can modify English itself. If your industry uses different terminology than a generic ERP assumes, you change the label. Your team works in the language of your business, not the language of your software vendor.

NetSuite handles multilingual differently. Users can select a preferred language from a fixed list of system-supported languages - and that per-user preference does work. But NetSuite's UI terminology is Oracle's to define, not yours. Based on Oracle's own documentation, users cannot modify what NetSuite calls things and cannot create a custom language. And the base language of your account - set the day your contract is signed - is permanently locked. Oracle's own documentation states that the company default language cannot be changed after the account is created.

With Carillon, your ERP adapts to your organization's vocabulary. With NetSuite, your organization adapts to Oracle's.

Source: Oracle NetSuite Documentation - Multi-Language Preferences - confirms base language cannot be changed after account creation.

Most software vendors use the acronym CRM to mean Customer Relationship Management. Carillon uses it to mean something broader and more accurate: Contact Relationship Management. The distinction isn't semantic - it reflects a fundamentally different design philosophy.

In Carillon, the system is built around two core concepts: Places and Persons. Places are organizations - customers, vendors, suppliers, ship-to locations, or any other entity your business interacts with. Persons are the individual contacts associated with them. The relationship between the two is many-to-many, and in the real world that matters constantly. A purchasing manager who handles ordering for five restaurant locations is one person - one phone number, one email address, one relationship. In Carillon, that person is one Contact record, linked to all five restaurant Places. When your sales rep calls that buyer, the activity is logged once and visible from any of the five locations. Carillon's design eliminates duplication, reduces hunting across records, and keeps activity history consolidated. Vendors, suppliers, employees, and customers all live in the same CRM architecture.

The same principle applies to organizations themselves. In Carillon, if a vendor and a customer are the same company - a supplier you buy from who also buys from you - they share a single Place record with a single ID. One address. One contact history. One record to maintain. The system understands that a Place can play multiple roles simultaneously without requiring separate records for each role.

In NetSuite, contacts are associated with a single parent company record by default - the architecture is one-to-many, not many-to-many. NetSuite does have an “Other Relationships” feature that allows a single entity record to hold multiple roles - for example, the same record being both a customer and a vendor. But that feature comes with documented limitations: it cannot be used during CSV imports, outstanding balances are not shared between the customer and vendor sides of the same record, and one NetSuite implementation partner advises always creating these relationships in a consistent sequence to avoid reporting inconsistencies. For the contact-to-multiple-entities scenario - one person linked to multiple organizations - NetSuite's native model does not support it. One of NetSuite's most credentialed independent experts has documented that achieving this requires a custom cross-reference record, and that even then the result “does not produce a user interface that is going to be easy for end-users.”

Your business relationships are more complex than a simple customer list. Carillon believes your CRM should reflect that complexity - not require custom development to handle it.

Sources: Prolecto Resources - “Breakthrough NetSuite's Contact to Entity Role Relationship” and “Unlocking NetSuite's Potential with the Purposeful Contact Model” (Marty Zigman, three-time NetSuite certified); Plative - “NetSuite Other Relationships” - documents limitations including CSV import restriction and shared balance limitation.

Global business is complicated enough without your ERP creating friction. Carillon's multicurrency functionality handles foreign currency transactions completely - invoicing in any currency, purchasing in any currency, and automatically calculating realized and unrealized foreign currency gains and losses as exchange rates move between the date of a transaction and the date of settlement. Carillon handles this automatically, eliminating the need for manual journal entries to capture the currency impact, and reducing or eliminating the month-end spreadsheet reconciliation that other systems require. The gain or loss is calculated and recorded by the system, correctly, every time.

NetSuite supports foreign currency transactions in its standard edition - you can invoice and purchase in currencies other than your base currency. However, multi-currency consolidation across entities with different base currencies requires the OneWorld edition, which is a higher-cost tier of the product. As one independent source states directly: “Standard NetSuite does not support multi-currency consolidation.” Oracle's own documentation confirms that each subsidiary's base currency is set at creation and cannot be changed afterward - a permanent architectural decision that must be made correctly from day one.

NetSuite's currency architecture is also built around standard two-decimal-place precision, and Oracle's own documentation acknowledges floating-point rounding limitations in currency fields for numbers with significant decimal complexity.

Carillon is actively expanding the number of decimal places on all amount fields throughout the system to handle Bitcoin and other digital currencies natively - because Bitcoin transactions require nine decimal places at the unit cost level, and two simply isn't enough. Development is underway with portions already completed.

Sources: Oracle NetSuite Documentation - Multiple Currencies in OneWorld, Enabling the Multiple Currencies Feature; BrokenRubik - NetSuite OneWorld Complete Guide 2026 (“Standard NetSuite does not support multi-currency consolidation”); Oracle NetSuite Documentation - Currency Field Limitations.

NetSuite training is expensive by any measure. Oracle does not publish official training pricing, but multiple independent sources report costs ranging from approximately $800 for a single one-day online course to $10,000 or more for company-wide platform access - and that is on top of an already substantial annual subscription. The more your team needs to know, the more you pay.

Carillon takes the opposite approach. Carillon ERP University is the same training program Carillon puts its own team through - built by an Adobe Captivate Specialist, hosted on Adobe Learning Manager (formerly Adobe Captivate Prime), and developed by Carillon's top management team. It's hands-on: the Authorized Consultant Course provides students with a copy of Carillon® ERP licensed for educational use, starting from a blank database and building all the way through shipping orders from multiple branches and collecting invoices. Upon completion, students can apply for Authorized Consultant status at no additional cost. All of this is available to the public for as little as $99 per month.

When one or more members of your team earn that certification before or during implementation, a train-the-trainer model becomes viable. Your people do meaningful implementation work themselves, and Carillon's consulting team is brought in strategically rather than continuously - potentially resulting in a dramatic reduction in professional services fees without sacrificing implementation quality.

Sources: Oracle does not publish official NetSuite training pricing. Figures cited reflect independently reported ranges: Anchor Group - $800 per one-day course; Suitepedia - $800–$3,000 per course; NetSuite Professionals community forum (September 2024) - LCS Company Pass pricing reported at approximately $10,000 undiscounted.

When something goes wrong in your business - a price that changed without authorization, a sales order that was modified after approval, an item cost that nobody can explain - the most important question is always the same: what happened, and who did it?

NetSuite has audit trail functionality, and for routine changes it provides useful information. But it has documented limitations. System notes track changes, not views - so you can see what was modified but not who simply looked at a record. Some large fields may not store before and after values. And critically, if a record is deleted, its associated system notes are no longer available. The line-level audit trail only tracks updates to existing line items - not their creation or deletion. In high-volume environments, the sheer volume of system notes can make meaningful analysis difficult without additional tools.

Carillon approaches this differently, and the foundation is Microsoft SQL Server - the most current release of which Carillon has always supported. Temporal Data is a native capability of SQL Server that operates at the database level - not the application layer. Changes to records throughout the system are tracked automatically and comprehensively: what the value was before, what it became, when the change occurred, and who made it. Almost every record in the Carillon database includes a last_maintained_by column that captures the network login ID of the last person to change that record - directly queryable without any additional audit configuration. Sales orders, production orders, item records, price files - this change history is available instantly, queryable directly through SQL, and connected to Power BI for analysis. This approach significantly reduces audit gaps and means that deleted records do not take their change history with them.

When your controller asks why a price changed three months ago, Carillon gives you the answer. That is what genuine data integrity looks like.

Sources: Netwrix - “Six Ways to Track Activity in NetSuite” - documents system note limitations including loss of history on record deletion; Oracle NetSuite Documentation - Line-Level Audit Trail.

In Carillon's view, there is a meaningful difference between ERP software designed around human productivity and ERP software designed around web architecture. It shows up every day in how your people get their work done.

ERP applications are built using one of two interface models. A Single Document Interface (SDI) presents one window at a time - to open something new, you close what you have, or open a second instance of the application entirely. A Multiple Document Interface (MDI) opens a single parent window and lets you work in as many child windows as you need simultaneously, all organized inside that one environment.

Carillon® ERP is a true MDI application. Your inventory window, your sales order entry screen, your customer record, and your price file can all be open at the same time - visible, accessible, and right where you left them. When your best customer calls while you are mid-entry on an unrelated transaction, you open their account without closing anything. When the call ends, you pick up exactly where you were.

NetSuite is a browser-based application. Multitasking means opening additional browser tabs - and that comes with real limitations. Users navigating multiple tabs can quickly get lost, accidentally clicking a link in the wrong tab and replacing its contents entirely - often requiring them to close several tabs and start over. Native NetSuite does not provide split-pane or side-by-side viewing of multiple records. A third-party Chrome extension called NetSuite SplitView - built by a NetSuite Certified developer and available on the Chrome Web Store - exists specifically to work around this limitation. Under our ground rules for this comparison, third-party add-ons do not count as native functionality. Without that extension, NetSuite users are working in tabs.

When you are evaluating ERP software, always ask the vendor how their interface handles multitasking. In Carillon's experience, the answer will tell you a great deal about how much they have thought about the people who will use it every day.

Source: NetSuite SplitView - Chrome Web Store (third-party extension built by a NetSuite Certified SuiteCloud Developer to add split-pane viewing to NetSuite).

In the promotional products industry, a “simple” customer order is rarely simple. A customer orders 100 embroidered hats. You issue a purchase order to your hat supplier, who ships the blank goods to your embroidery decorator. The decorator finishes the hats and ships them directly to your customer. Then - before anything has shipped - the customer calls and changes the order from 100 to 200.

That is not an edge case. That is Tuesday. And your ERP needs to handle it without creating manual work for your team.

Carillon was designed for exactly this workflow. From Sales Order Entry, you can automatically generate purchase orders to multiple suppliers - one per line item - in a single step. When the customer calls and changes the quantity, you update the sales order. Carillon automatically generates formal Change Orders for the affected purchase orders, complete with revision history. Your vendors receive a revised PO immediately. You have a documented record of every change. When the decorator ships the finished goods and notifies you, Carillon's Direct Ship Confirmation window creates both the vendor voucher and the customer invoice simultaneously - one confirmation, two documents, done.

NetSuite supports basic drop shipping - but its native model is vendor-to-customer. A two-supplier chain (blanks supplier to decorator to customer) does not fit that model cleanly. The closest native alternative is NetSuite's Outsourced Manufacturing workflow, which is a BOM- and work-order-oriented process requiring Assembly Items, Advanced BOM, Work Orders, and additional modules. That is a manufacturing model, not a sales-order-driven purchasing workflow.

On change orders: NetSuite can update linked drop ship PO quantities under certain conditions, but Oracle's documentation confirms this preference defaults to disabled, applies only before fulfillment or receipt, and does not create a formal PO change order with revision history. When a vendor has already received the original PO, Oracle's guidance is to edit the PO manually, note “revised order” in the Vendor Message field, and resend it. On billing: with both Advanced Shipping and Advanced Receiving active, Oracle states the sales order and purchase order are not automatically billed - they must be billed separately. Creating both the vendor voucher and customer invoice in a single confirmation step is not standard NetSuite behavior.

For promotional products distributors, customer changes before shipment are routine. An ERP that requires your team to manually track down linked POs and resend revised copies every time a customer calls is not the workflow most promotional products distributors want from their ERP.

Source: Oracle NetSuite Documentation - Drop Shipping, Outsourced Manufacturing, and Advanced Shipping/Receiving billing behavior.

In the promotional products industry, artwork isn't an afterthought - it's the product. A customer orders branded cups. The front needs their logo. The back needs their tagline. Each of those regions requires its own artwork file, its own approval, and its own revision history. Before a single cup goes to production, you may go through three or four rounds of proofs: create the draft, send it for approval, receive feedback, revise, repeat. And when that same customer reorders six months later, you want their approved artwork ready to go - not buried in someone's email.

Carillon manages this entire workflow natively. Multiple print regions per item. A full art approval cycle with revision history - from first draft through final sign-off. Customer-level artwork libraries, so approved files are stored against the customer record and instantly available on future sales orders. The artwork process and the order process are part of the same system, not separate tools that need to be kept in sync.

Based on Oracle's own published materials, this capability does not appear to be part of native NetSuite functionality. Oracle's own published article - titled “4 Problems that Keep Promotional Product CEOs Up at Night” - candidly acknowledges that artwork management is one of those problems, and directs readers to a third-party add-on called eXtendTech, which Oracle describes as having built “an artwork management and collaboration tool” specifically to fill the gap. The gap is real enough that Oracle named it on their own website.

NetSuite's general-purpose SuiteFlow approval engine can route financial transactions through an approval chain. It was not designed specifically to manage artwork proofs, print regions, or customer creative libraries. Those are not the same thing - and in the promotional products world, the difference matters every single day.

Source: Oracle NetSuite - “4 Problems that Keep Promotional Product CEOs Up at Night” - acknowledges artwork management as an industry gap and references eXtendTech as a third-party add-on to address it. netsuite.com

In Reason #20, we described why Carillon's Multiple Document Interface outperforms NetSuite's browser-tab model for day-to-day productivity. Multiple windows open simultaneously. Your sales order, your customer record, your inventory screen, and your price file - all visible and accessible at the same time. No lost context. No accidentally replacing a tab you needed.

The natural follow-up question is: what about remote workers? What about the CFO reviewing transactions from home on a Mac? The warehouse supervisor with a tablet? The sales rep on the road who isn't carrying a Windows laptop?

Carillon now supports Microsoft Azure Virtual Desktop. AVD streams a complete Windows desktop from Microsoft's Azure infrastructure to any device - Mac, iPad, Android tablet, Chromebook, thin client, or any other hardware. The user sees and interacts with the full Carillon MDI experience exactly as if they were sitting at a Windows workstation. Every window. Every feature. Every keyboard shortcut. On whatever device they happen to be holding.

NetSuite's answer to remote access has always been simple: it runs in a browser, so it runs everywhere. That is true. But as we established in Reason #20, a browser tab is not the same as a productive work environment for someone who needs to multitask across an ERP system all day. Remote access to a limited interface is still a limited interface.

With Carillon and Azure Virtual Desktop, remote workers get the same experience as in-office workers - not a stripped-down web version of it. That matters for adoption, for productivity, and for the long-term value of your ERP investment.

Windows Hello for Business is Microsoft's enterprise authentication platform - the technology behind fingerprint readers, facial recognition, and PIN-based login on Windows devices. It is fast, phishing-resistant, passwordless, and increasingly the standard for how organizations secure access to everything on their network.

Carillon supports Windows Hello for Business natively. When a user authenticates to Windows - whether with a fingerprint, a face scan, or a PIN - that authentication is also their Carillon authentication. Carillon does not require a separate login screen, username, password, or additional authentication prompt. The ERP opens because Windows is already open. This applies equally whether Carillon is deployed on-premises or running through Azure Virtual Desktop in the cloud.

NetSuite is a browser-based application. Achieving a similar passwordless experience with NetSuite requires configuring SAML Single Sign-On between NetSuite and an external identity provider - typically Microsoft Entra ID. That configuration involves enabling SAML SSO within NetSuite, uploading identity provider metadata files, assigning SAML permissions to user roles, and maintaining the integration over time. Even when properly configured, the user's Windows Hello authentication unlocks their Entra ID session, which then triggers a browser-based SAML redirect into NetSuite. It works - but it is an authentication chain built from separately configured components, not a native integration.

For organizations that have not configured SAML SSO, NetSuite authentication remains a separate browser-based login flow, with mandatory two-factor authentication required for administrator and other sensitive roles.

The difference in practice is straightforward. Carillon users touch a fingerprint reader and their ERP is open. NetSuite users open a browser, navigate to a URL, and complete an authentication flow. In security terms, both can be made strong. In productivity terms, they are not the same experience.

Source: Oracle NetSuite Documentation - SAML Single Sign-on setup requirements; Microsoft - Windows Hello for Business overview.

For most finance teams, the ideal reporting workflow is simple: get the data you need, in Excel, without calling IT, without waiting for a consultant, and without learning a new tool. With Carillon, that workflow is exactly what you get.

Carillon's database runs on Microsoft SQL Server - the most current release of which Carillon has always supported - one of the most widely supported database platforms in the world. Excel connects to SQL Server natively, using the built-in Get Data from SQL Server option. A standard SQL Server connection requires no middleware, API wrappers, or third-party connectors. Your controller opens Excel, connects to the Carillon database, and pulls data directly.

What makes this genuinely accessible - not just technically possible - is how Carillon names its data. Table names and column names throughout the Carillon database are written in plain English. Customer invoices live in invoice_hdr and invoice_line. There are no intentionally obscure table names or internal-only codes that require a consultant just to identify common accounting data. A finance professional who has never written a SQL query in their life can look at those names and understand what they are looking at.

Carillon ERP University takes this a step further. In addition to its full ERP implementation curriculum, Carillon ERP University includes a hands-on course specifically teaching users how to write SQL SELECT statements against the Carillon database. A controller or accounting manager who completes that course can build their own Excel reports - pulling live data from any table, joining headers to lines, filtering by date range or customer - without involving a developer or a consultant. In Carillon's experience, that is a skill that pays for itself the first time it replaces a reporting request that would otherwise have taken days.

NetSuite takes a fundamentally different path. Connecting Excel to NetSuite requires a separately licensed module called SuiteAnalytics Connect and the download and installation of a dedicated ODBC driver. Once connected, users must navigate NetSuite's internal table structure - which multiple implementation partners describe as requiring significant technical knowledge to use effectively. Third-party tools exist in the NetSuite ecosystem for the sole purpose of shielding non-technical users from that complexity. Oracle's own documentation also confirms a hard limit of 999 fields per query - a constraint that can cause errors on complex tables with many custom fields.

With Carillon, your finance team connects directly, queries confidently, and builds the reports they need. With NetSuite, the same task requires a module, a driver, technical expertise, and quite possibly an outside consultant.

Sources: Oracle NetSuite Documentation - SuiteAnalytics Connect, 999-field query limitation; Solution 7 - “requires a semi-technical skillset” and “need to understand the technical back end of NetSuite”; Zone & Co - SuiteAnalytics Connect overview.

Financial statements are not a commodity. A Controller or CFO who needs a board-ready reporting package - income statement, balance sheet, cash flow, budget vs. actual, fund statements, department breakdowns, all formatted consistently and printed in one click - needs a financial statement generator that can actually do the job. Carillon's can. NetSuite's native tools may require outside help for more complex reporting needs.

Carillon's financial statement generator is defined entirely within Carillon. You specify exactly which account balances belong in each position of each statement - month-to-date actuals, year-to-date actuals, MTD budget, YTD budget, prior year comparisons, fund balances, encumbrances, and more. When the statement is generated, Carillon pushes the output directly into Microsoft Excel via OLE - no export, no import, no re-keying of any kind. The data arrives in Excel live, and everything Excel offers is immediately available: fonts, colors, charts, formulas, conditional formatting, and the ability to embed the finished statement directly into a Microsoft Word document for a board package or a 10-K filing. A Carillon-provided Excel macro enables drill-down from any number on the statement directly to the underlying transaction detail. When you are ready to distribute, you can print the entire reporting package - every statement, every schedule - with a single mouse click, right from within Carillon. Consolidations across multiple entities are handled the same way.

The practical limits of Carillon's financial statement generator are Excel's own limits, which for typical financial reporting purposes are unlikely to be encountered. Carillon itself imposes no row limits, no section restrictions, no multiperiod constraints. Every time a limitation has been identified in the generator over the years, Carillon has built in the missing functionality. That is not a marketing claim - it is a description of how the product has been developed for over three decades in response to real client needs.

NetSuite's Financial Report Builder has documented limitations. Oracle's own documentation states that if you create a custom Cash Flow Statement that includes custom sections, “its value for the Cash at Beginning of Period row is likely to be incorrect” unless an additional workaround custom statement is created. Custom sections with overlapping account criteria produce unexpected results, with NetSuite deciding which section an account belongs to rather than the user. Duplicate account combinations silently display zeroes after their first appearance. Report results have documented row limits. Multi-period side-by-side reporting - something as routine as 12 months of P&L columns on one statement - requires looking up each period separately and manually assembling the results. Consolidated multisubsidiary financial statements require the OneWorld edition, a higher-cost tier of the product not included in a standard NetSuite license.

The NetSuite ecosystem has responded to these limitations by producing dedicated third-party financial reporting tools - products like Spreadsheet Server - that address reporting needs beyond what NetSuite's native Financial Report Builder produces. One industry analyst notes that NetSuite customers sometimes limit their reporting to “strictly what's legally required” because building anything more comprehensive is simply too difficult within the native tools.

With Carillon, your finance team produces the reporting package your CFO actually needs - in one click, with full Excel formatting, drill-down to transaction detail, and no third-party tools required.

Sources: Oracle NetSuite Documentation - Creating a Custom Financial Statement Section - confirms Cash at Beginning of Period is “likely to be incorrect” in custom Cash Flow Statements; Oracle NetSuite Documentation - Row Limitations for Report Results; Oracle NetSuite Documentation - OneWorld Financial Statements; insightsoftware - “The Secret to Creating the NetSuite Financial Reports You Have to Have.”

Every accounting team knows the pressure of period-end close. The last thing that pressure needs is an ERP system that creates dependencies between periods - one that makes it harder for your team to work freely across them, requires fudging transaction dates to get postings into the right period, or adds steps before you can start processing the new year's payroll. Carillon eliminates all of that. NetSuite's architecture introduces it.

Carillon is a period-driven system. You define your periods - up to 366 per year, with user-defined date ranges for each period, covering any range from 1950 to 2049 - and all of them can be open simultaneously. Closing a period is a single checkbox. Check it and no further transactions can post to that period. Uncheck it and the period is open again - even if it is years in the past. If all periods in a year are closed, the year is closed. If you need to reopen a year from five years ago, you uncheck the relevant period checkboxes. There is no checklist, no sequence of required tasks, no cascading effect on subsequent periods. A transaction posts to the period you explicitly assign it to. Your team can be posting into last month, this month, and next month simultaneously with no dependency between them. You never have to complete year-end 1099 or W-2 processing before beginning payments in the new year.

NetSuite transactions carry two separate fields: a transaction date and a posting period. Financial statements are prepared based on the posting period, not the transaction date. When a period is closed, any transaction dated within that period must be redirected to an open period - either by changing the transaction date or by manually selecting a different posting period. NetSuite provides a system-level preference called “Allow Transaction Date Outside of Posting Period” with three settings: Disallow, Warn, or Allow. The existence of that preference - and the fact that it requires a deliberate configuration decision - reflects how common the mismatch problem is in practice. NetSuite implementation partners document date/period mismatch as a recurring issue that requires saved searches and manual cleanup, noting that “a company may want to enter the actual date of a vendor bill, but since the previous period has already been closed, they will post to the current period for financial purposes.”

NetSuite's period close process involves a multi-step sequential checklist. Oracle's own documentation states that before year-end close can occur, all periods in the year should be closed. Each period has a checklist of tasks - locking A/R, locking A/P, locking payroll, resolving foreign currency revaluations, eliminating intercompany transactions, and more - that are intended to be completed in sequence. Oracle's documentation also states that payroll year-end tasks should be completed before year-end close. If a closed period needs to be reopened to make an adjustment, NetSuite requires all subsequent closed periods to be reopened as well - a cascading effect that means re-closing multiple periods afterward. NetSuite's period format choices are also limited to three structures: standard calendar months (12 periods), four-week periods (13 periods), or a four-four-five week cycle (13 periods).

Carillon's period management was designed around how accounting teams actually work - with the flexibility to move freely across periods, the simplicity of a single checkbox to open or close them, and no dependencies that turn a routine adjustment into a multi-step re-close process.

Sources: Oracle NetSuite Documentation - Year-End Closing (“Before year-end close, you should close all of the periods included in the year”), Setting Up Accounting Periods, Accounting Period Close; Optimal Data Consulting - “Understand the Date and Posting Period in NetSuite”; Concentrus - “Date/Period Mismatch” - documents the mismatch problem and cleanup process.

Carillon's founder, Larry R. Pettit, CPA, CITP, CGMA, is a former Senior Audit Manager at Arthur Andersen & Co. There is nothing more important to him than protecting the integrity of the audit trail. A common source of fraud is employees changing the details of an approved transaction after the fact - and the absence of automatic controls to detect those changes means the manipulation often goes unnoticed until significant damage has been done.

Carillon's response to that risk is architectural. Once a financial transaction is approved in Carillon, it cannot be changed - period. A user can retrieve an approved transaction to view it, but the Save button is disabled. There is nothing to click, nothing to override, and no permission level that unlocks editing. The transaction is what it was when it was approved, and it will always be what it was when it was approved. If a correction is needed, the appropriate accounting remedy applies - a debit or credit memo, a journal entry, or a reversal - each of which creates its own traceable record rather than overwriting the original.

Access to every transaction window in Carillon is individually rights-controlled. A user must have explicit rights to a window to enter or view a transaction at all. Approving transactions is a separately granted right, and no debits or credits post to the general ledger until approval occurs. Sales orders and purchase orders are the two transaction types where post-approval changes make operational sense - and even there, Carillon enforces controls. A change to an approved sales order requires re-approval by someone with sales order approval rights. A change to an approved purchase order automatically generates a formal Change Order with a complete revision history.

By default, Carillon users also have no database rights. Even a user with the technical knowledge to manipulate data directly cannot do so without database access being explicitly granted - a separate infrastructure-level control that is off by default.

When combined with Carillon's SQL Server Temporal Data feature - which tracks the full before-and-after history of every record change at the database level, including the last_maintained_by column that captures the network login ID of the last person to touch a record - Carillon's audit trail may not be perfect, but Carillon is not aware of any known faults in it.

NetSuite does have an audit trail, and for many organizations it provides meaningful visibility. But in Carillon's view it is not as immutable as Carillon's. Oracle's own documentation confirms that by default, approved transactions in NetSuite can be edited within the application by users with sufficient permissions. After editing an approved vendor bill, a user can reset the approval status to Approved themselves - without routing back to the original approver and without any notification being sent. Oracle's own documentation further confirms that the default vendor bill status can be configured to auto-approve, bypassing human review entirely. Locking a transaction after approval is not default NetSuite behavior - it requires a custom SuiteFlow workflow to be deliberately designed and deployed. Without that custom implementation, the door to post-approval editing remains open.

Sources: Oracle NetSuite Documentation - Setting the Default Vendor Approval Status; Oracle NetSuite Documentation - Standard Vendor Bill Approval FAQ; Oracle NetSuite Documentation - Customizing for the Vendor Bill Approval Workflow.

Every ERP system tracks inventory. The more important question - and the harder one to answer - is how much of that inventory you can actually commit to a new order right now, while reducing the risk of overcommitting inventory already needed elsewhere.

Carillon answers that question with a calculation called Available to Sell. It starts with on-hand inventory at the item's location and nets the relevant sources of supply and demand used by Carillon's Available to Sell calculation - existing sales orders, production orders, planned component requirements for manufacturing, and planned material issuances to jobs - on a day-by-day basis through the item's replenishment lead time. The result is a calculated Available to Sell quantity intended to help a salesperson understand how much can be committed now while reducing the risk of creating a future shortage or missed obligation. Beyond the lead time horizon, Carillon assumes Available to Sell is unlimited - because by then, replenishment is possible.

Two details make this meaningfully different from what many item-level availability checks offer. First, the demand side of the calculation includes component requirements for production orders and planned material issuances to jobs - meaning if your warehouse has 500 units of a raw material but 300 are already required to fulfill planned production, your salespeople see 200 available to sell, not 500. Second, the calculation is performed in real time, every time availability is checked. For sales-order decisions, Carillon's view is that availability should be calculated at the moment the decision is being made. In Carillon ERP's opinion, batch processing should be relegated to the 1980s.

NetSuite offers an Available to Promise feature, and Oracle's documentation states that ATP reviews expected receipts from purchase orders, work orders, and transfer orders, along with expected fulfillments on sales orders and transfer orders. The distinction we are making is more specific: Carillon's Available to Sell is designed to net item and location availability through the replenishment lead-time horizon, including component requirements for production and planned material issuances to jobs, at the moment availability is checked. Based on the public Oracle documentation we reviewed, we have not found documentation showing that NetSuite's native ATP exposes the same component-level, job-material-aware available-to-sell calculation to sales users without additional configuration, customization, or process design.

Sources: Oracle NetSuite Documentation - Available to Promise; Oracle NetSuite Documentation - Available to Promise Methods; Salora ERP case study describing one custom SuiteScript-based ATP dashboard implementation.

Many businesses sell the same product in more than one unit of measure - cases and bottles, boxes and eaches, bulk and individual units. When a customer orders the smaller unit, product typically has to move through a repack or breakdown operation before it can ship. That repack queue represents real demand on case inventory - demand that exists the moment the order is entered, long before a case physically moves to the repack room.

Availability logic that only looks at physical case commitments can overstate case availability. The result is that a salesperson checking case availability may see a number that does not account for what the repack room has already claimed - and can promise inventory that may not be free to sell.

Carillon tracks pending repack orders, calculates how many cases need to be reserved to fulfill them, and reflects that commitment in the case Available to Sell figure in real time. If 50 orders are each waiting for 2 bottles of a particular wine - or 2 individual units from a case of any product - Carillon knows how many cases are spoken for and removes them from the available-to-sell figure before a salesperson ever sees the number. The repack queue is treated as demand, because it is.

NetSuite supports multiple units of measure and can represent the same item in different purchase, stock, and sales units. The distinction here is not basic unit conversion. The distinction is whether pending repack obligations are automatically treated as demand against case-level availability before the cases are physically moved, consumed, or otherwise committed. Based on the public Oracle documentation we reviewed, we have not found documentation showing that NetSuite's native ATP calculation specifically treats a repack-room queue as a demand signal that reserves case inventory for pending each or bottle orders in the way Carillon's Available to Sell calculation does.

Sources: Oracle NetSuite Documentation - Available to Promise; Oracle NetSuite Documentation - Available to Promise Methods; Oracle NetSuite Documentation - Multiple Units of Measure.

The previous reason describes how Carillon protects case inventory from being oversold into the repack queue. This reason describes the equally important problem on the other side: avoidable sales friction that may not need to exist.

When a salesperson checks availability on a bottle or individual unit, availability logic that only looks at loose units in the repack room may understate what is actually available. Without visibility into uncommitted case inventory that could be broken down, the salesperson may decline the order - or go looking for answers manually. That can create avoidable sales friction: the inventory may exist in convertible form, but the salesperson may not see it without manual follow-up.

Carillon calculates bottle and each availability by looking beyond the repack room's on-hand quantity. It identifies cases that are not otherwise committed - not already spoken for by case-level sales orders, production requirements, or the repack queue obligations described in the previous reason - and factors the units those cases could yield into the bottle Available to Sell figure. The result is a number that reflects what may be available after considering convertible case inventory, not just what is already loose and ready to ship.

NetSuite's ATP documentation describes availability using expected supply and demand from transaction sources such as purchase orders, work orders, transfer orders, and sales orders. NetSuite also supports multiple units of measure. The distinction here is narrower: Carillon can treat uncommitted case inventory as a potential supply source for bottle or each availability, after accounting for case-level orders, production requirements, and pending repack obligations. Based on the public Oracle documentation we reviewed, we have not found documentation showing that NetSuite's native ATP calculation performs this same repack-aware case-to-each availability calculation as part of the standard ATP process.

Sources: Oracle NetSuite Documentation - Available to Promise; Oracle NetSuite Documentation - Available to Promise Methods; Oracle NetSuite Documentation - Multiple Units of Measure.

Two of the most expensive loading-dock errors are simple to describe and costly not to catch. Something that was supposed to ship does not make it onto the truck. Or something that was not supposed to ship does — whether by mistake, confusion, or unauthorized handling. A warehouse associate loads a high-value bottle in place of a lower-value bottle. A case intended for one customer ends up on another customer's truck. An item that was never assigned to the shipment reaches the dock. In each case, the best time to catch the problem is before the truck door closes.

Carillon addresses that risk with a methodology called Scan Scan.

During receiving, every case that enters the warehouse receives a reliable barcode identity. If the manufacturer's barcode meets Carillon's requirements, Carillon can use it. If it does not, Carillon prints one. From that point forward, the case has a verified identity inside the Carillon warehouse process.

When an order is selected for picking, a shipping barcode is printed and applied to each case designated for that order. That shipping barcode ties the case to its shipping destination — including the truck, route, or load assignment used by the operation. The item identity and the shipping destination are connected before the case reaches the loading dock.

At the dock, both barcodes are scanned as each case is loaded. It is the combination of the two scans together that provides the control — confirming that the right item is going to the right truck. In Carillon's experience, the process typically takes about one second per case and is designed to fit into the normal loading workflow. If the combination does not match — if the wrong item was labeled, if the case belongs on a different truck, or if the case has no valid shipping assignment — a large red alert appears at the dock so the exception can be addressed before loading proceeds.

That creates a final verification point at the last practical moment before shipment. Scan Scan is designed to catch both categories of error: the item that is missing from the load and the item that does not belong on the load. It verifies the product and the truck in the same dock-door workflow, case by case, load by load.

The most important distinction is intentional substitution. A barcode-enabled picking process can catch many honest mistakes, but it does not necessarily prove that the physical case being loaded is still the same case that was picked. If a warehouse associate scans the expected item during picking and then places a different physical case into the shipping flow — or applies the correct shipping label to the wrong physical case — the control must catch that mismatch later. Carillon's Scan Scan is designed for exactly that scenario. At the dock, the combination of both scans verifies the product's own identity and the truck or load assignment as two independent facts. The case cannot proceed merely because the paperwork indicates it was picked correctly. The physical product itself must match the load.

Carillon's barcode methodology also extends into the repack room. Special barcodes are used for cases that move through repack or breakdown operations, maintaining chain of custody and item identity even when a case is broken into individual units. That allows dock-door verification to remain reliable for repacked product as well as full-case product.

NetSuite does have meaningful warehouse management capabilities. NetSuite WMS — Oracle's own add-on module, not a third-party product — supports mobile RF barcode scanning across warehouse workflows, including receiving, putaway, picking, packing, shipping, cycle counting, and related warehouse processes. Oracle's NetSuite Ship Central extends packing and shipping capabilities through tablet and kiosk-based workflows, including carton and pallet handling, carrier integration, label generation, and shipping workflow support. These are real controls, and they can meaningfully reduce warehouse and fulfillment errors earlier in the process.

The distinction Carillon draws is narrow and specific. Based on the public Oracle documentation we reviewed, we found documentation for barcode-enabled NetSuite WMS and Ship Central workflows, including picking, packing, and shipping processes. But we have not found documentation describing a native NetSuite WMS or Ship Central workflow that functions as a dock-door gate by scanning both item identity and truck or load assignment on every case as it is physically loaded, producing a visible dock alert when the combination fails, and allowing the exception to be addressed before the case is loaded. Buyers evaluating this capability should ask Oracle or their NetSuite representative to demonstrate that exact documented native workflow and test it against both failure modes directly: a required case missing from the truck, and an unauthorized or wrong case being placed on the truck.

Carillon does not just ask whether the pick process says the right item was picked. Carillon asks whether the physical case now being loaded is the right case for this truck. That is the difference between trusting the pick and verifying the load.

Sources: Oracle NetSuite — Warehouse Management System product page; Oracle NetSuite — Mobile Warehouse Management product page; Oracle NetSuite Documentation — Bar Code Setup for NetSuite WMS; Oracle NetSuite Documentation — NetSuite Ship Central; Oracle NetSuite Documentation — Shipping Orders.

Not all jobs are created equal. A simple service call and a multi-year construction project are both jobs — but they do not require the same structure to manage effectively. An ERP that treats every job the same way can either overwhelm simple jobs with unnecessary complexity or require significant additional configuration to give complex jobs the granular cost control they need.

Carillon solves this with a flexible, hierarchical job costing structure that adapts to the job, not the other way around. Every job can have unlimited sub-jobs. Every sub-job can have unlimited phases. Every phase can have unlimited tasks. Cost codes typically identify the type of work being performed and map directly to a general ledger account. Cost types — such as labor, material, overhead, subcontracting, and other categories — provide an additional layer of detail for capturing and reporting the nature of every dollar spent.

Just as important, sub-jobs, phases, and tasks are optional and are configured on a job-by-job basis. You can use all three levels, one or two levels, or none of them. A simple job stays simple. A complex multi-phase, multi-site project gets the structure it requires. The same system handles both without forcing every job into the same template.

NetSuite does offer project and job costing functionality. Oracle's own documentation describes project budgeting at the project and task level, with task-level budgets rolling up to the project. NetSuite's project task structure also supports phases and nested tasks, and Oracle markets NetSuite Construction ERP for construction businesses. For many service-oriented businesses, and for some construction businesses depending on their requirements, these options may be sufficient.

The distinction is depth and fit. NetSuite's documentation shows that when multiple projects are involved on sales transactions, project consolidation and billing behavior depends on configuration choices such as Consolidate Projects on Sales Transactions, Consolidated Payments, and line-level billing schedules. For businesses that need sub-job-level cost reporting within a single job structure, flexible work breakdown structures, cost codes mapped to the general ledger, and job-by-job hierarchy control without relying on a construction-specific add-on, those capabilities are built directly into Carillon's core product.

Public third-party NetSuite construction materials also describe NetSuite implementations being paired with construction-specific solutions such as Full Clarity Construction for NetSuite to extend capabilities including AIA billing, retainage automation, WIP reporting, committed-cost tracking, Schedule of Values support, and change-order workflows. Those may be valuable tools, but under this comparison, third-party or separately licensed add-ons are not treated as native NetSuite functionality.

For a construction company, a manufacturer, a professional services firm, or any business managing jobs of varying complexity, Carillon believes the ability to structure each job on its own terms — with as much or as little hierarchy as the job requires, natively and without add-ons — is not just a configuration preference. It is the foundation of accurate job cost reporting.

Sources: Oracle NetSuite Documentation — Job Costing and Project Budgeting; Oracle NetSuite Documentation — Project Tasks; Oracle NetSuite Construction ERP; Oracle NetSuite Documentation — Using Consolidated Billing for Projects and for Payments; Oracle NetSuite Documentation — Billing and Project Consolidation; Softype — "NetSuite for Construction: Project Tracking & Job Costing ERP"; Prolecto Resources — "Drive NetSuite with Alternative Project Concepts."

For businesses recognizing revenue on long-term projects using the percentage of completion method, accuracy is the foundation of financial reporting and audit support. Two factors determine whether that calculation is trustworthy: what goes into it, and when it updates.

Carillon calculates percentage of completion using a cost-to-cost approach - comparing eligible actual posted project costs to the total budgeted cost. Every relevant project cost type can flow into the calculation: materials, subcontractor costs, equipment, overhead, labor, and other project costs. Time entries carry a cost-of-service rate, so labor is converted into the company's home currency and included in total project cost alongside other cost types. The result is a completion percentage that reflects the economic progress of the job. And when costs are posted or budgets are revised, the completion percentage updates immediately - no scheduled processing, no separate recalculation step, and no manual intervention.

Carillon also distinguishes between financial reporting and project management visibility. For financial reporting purposes, percentage of completion is based on actual posted costs. But project managers often need to see more than posted costs. When a purchase order is issued, that money may not yet be an accounting cost - but operationally, it may already be committed. Carillon supports committed costs for project management reporting, while excluding those commitments from the formal percentage-of-completion calculation used for financial reporting.

NetSuite also supports percentage-of-completion revenue recognition. Oracle's documentation for standard percent-complete project revenue recognition states that project completion is calculated based on entered and approved project time entries, and Oracle's example calculates completion using logged hours compared with estimated hours. That is a time-based calculation. For a project where labor is the dominant cost, that may be sufficient. For a project with significant front-loaded material purchases, subcontractor costs, equipment costs, or other non-labor costs, a time-entry-based calculation may not reflect the same economic progress as a cost-to-cost calculation.

NetSuite can also support a cost-based approach through Oracle's Project Cost-to-Cost Percent Complete SuiteApp. Oracle describes that SuiteApp as a cost-based percent-complete approach that calculates completion based on budget and cost, and its documented formula is Actual Cost till Date divided by Cost Budget. Oracle also documents default labor and non-labor datasets, and allows additional datasets to be configured. That is an important NetSuite capability and should be acknowledged. The distinction is that Oracle documents this as a SuiteApp-driven process, with projects submitted for processing by accounting period through the Update Project Cost Percent Complete page. Oracle's own documentation also notes execution and configuration constraints, including UI-only rule creation and an approximate 5,000-project execution limit. In Carillon's view, a periodic or submitted calculation is a lagging indicator - Carillon's completion percentage updates as the underlying cost and budget data changes.

NetSuite's revenue management process is not documented as a transaction-by-transaction, real-time recalculation model. Oracle's documentation states that revenue recognition plans may be updated automatically or manually, and that automatic revenue plan updates occur every three hours. Oracle also documents a separate percent-complete override recalculation option that can recalculate percent complete every eight hours for projects with the applicable project status, with manual recalculation also available. In Carillon, the percentage-of-completion value used to support revenue recognition is a live calculation based on actual posted project costs and current budget data. In NetSuite, Oracle documents percentage completion, revenue plans, and revenue recognition journal entries as related but separate processing steps. That distinction matters for companies that want the revenue recognition basis to reflect project cost activity immediately.

For any business using the percentage of completion method, Carillon believes the question is straightforward: should the completion percentage supporting revenue recognition be based on eligible actual posted project costs against total budgeted cost, updated as soon as the underlying transactions change? For Carillon, the answer is yes - and that calculation is built directly into the core job costing system.

Sources: Oracle NetSuite Documentation - Using Percent-Complete Revenue Recognition for Projects; Oracle NetSuite Documentation - Journal Entries for Percent-Complete Revenue; Oracle NetSuite Documentation - Advanced Revenue Management for Projects; Oracle NetSuite Documentation - Project Cost-to-Cost Percent Complete SuiteApp; Oracle NetSuite Documentation - Updating Project Cost Percent Complete; Oracle NetSuite Documentation - Creating a Project Cost Percent Complete Rule; Oracle NetSuite Documentation - Project Cost-to-Cost Percent Complete SuiteApp Limitations; Oracle NetSuite Documentation - Updating Revenue Recognition Plans; Oracle NetSuite Documentation - Using the Percent Complete Override Subtab; Oracle NetSuite Documentation - Recalculate Percent Complete Override.

Some businesses run on standard workflows that fit neatly into an ERP system's built-in screens. Others have processes, data structures, reporting requirements, or integration needs that require more direct access to their ERP data. For those businesses, the ability to build custom front ends, custom reporting tools, live reporting connections, and bespoke integrations is not a technical luxury. It can be an operational requirement.

With Carillon, in standard deployments that provide client-managed or dedicated database access, each client's ERP data resides in a dedicated Microsoft SQL Server database controlled by that client, subject to the client's security policies, license terms, and supportable implementation practices. Authorized developers, reporting tools, and approved integrations can connect using standard SQL Server access methods. For example, Power BI supports SQL Server connectivity using Import or DirectQuery modes where configured appropriately.

Direct access does not mean uncontrolled access. It should be managed through appropriate database permissions, user roles, encryption, network controls, monitoring, and change-management practices. The distinction is that Carillon can provide authorized SQL-level access to the client's own ERP data without requiring every reporting or integration request to pass through a vendor-controlled application API.

NetSuite also offers substantial developer and integration capabilities. Oracle documents several NetSuite integration options, including CSV Import, SuiteTalk REST Web Services, RESTlets, and SuiteTalk SOAP Web Services. NetSuite also supports SuiteScript, SuiteQL, and SuiteAnalytics Connect. These are real capabilities, and for many organizations they provide a controlled and effective way to integrate with NetSuite.

The architectural distinction is that NetSuite's publicly documented external access methods are Oracle-managed interfaces, not customer-held direct SQL access to the underlying NetSuite production database. That design is consistent with NetSuite's cloud ERP and multi-tenant SaaS model. Some organizations value this controlled access model because it helps enforce NetSuite permissions, workflows, validation logic, and application rules. The question Carillon raises is not whether that layer has value. It does. The question is whether that layer should be the customer's only practical path to ERP data when the business requires direct reporting, custom applications, or specialized integrations.

The practical implications matter. SuiteQL queries executed through REST web services can return a maximum of 100,000 results. NetSuite web services and RESTlets are also subject to Oracle's documented concurrency governance, with limits based on service tier and SuiteCloud Plus licensing. Custom records and fields are supported, but their availability depends on account-specific metadata, enabled features, permissions, record type, and the access channel being used.

SuiteAnalytics Connect is a meaningful capability and should be acknowledged. It provides ODBC, JDBC, and ADO.NET drivers for obtaining NetSuite data through Oracle's Connect Service. Oracle describes SuiteAnalytics Connect as a read-only method for obtaining NetSuite data and states that it cannot be used to update NetSuite data. Oracle also documents that SuiteAnalytics Connect accesses NetSuite data through the NetSuite2.com analytics data source, a schema optimized for reporting and analytics. In other words, SuiteAnalytics Connect can provide a database-like reporting experience, but it remains an Oracle-provided access service built on a reporting schema, not direct access to the underlying production database.

Because Oracle does not publish customer-specific NetSuite pricing for these access-related capabilities, Carillon was unable to determine from public sources what, if any, additional NetSuite fees an organization would need to pay to enable or expand this functionality. This is not a claim that Oracle necessarily charges additional fees; it is a statement that the answer is not publicly determinable. With Carillon, the incremental software license fee charged by Carillon for authorized direct SQL access to the client's Carillon database is $0.00.

For businesses whose operations require custom front ends, live SQL-based analytics, bespoke integrations, or controlled direct access to ERP data, Carillon believes the question is architectural: should access to ERP data be exclusively mediated by vendor-provided interfaces, or should authorized direct SQL access be available when the business needs it?

With Carillon, in standard supported deployments, authorized access can be direct and client-controlled. With NetSuite, external access is powerful and mature, but it is mediated through Oracle-managed APIs, query tools, and analytics services. The difference is not whether NetSuite supports integrations. It does. The difference is where control over data access resides.

Sources: Oracle NetSuite Documentation, SuiteAnalytics Connect Overview (docs.oracle.com): confirms read-only access and that the Connect Service cannot be used to update NetSuite data; Oracle NetSuite Documentation, SuiteAnalytics Connect Data Source (docs.oracle.com): confirms NetSuite2.com as the analytics data source; Oracle NetSuite Documentation, SuiteCloud Platform Integration (netsuite.com): documents CSV Import, SuiteTalk REST Web Services, RESTlets, SuiteTalk SOAP Web Services, and SuiteAnalytics Connect as external access methods; Oracle NetSuite Documentation, Executing SuiteQL Queries Through REST Web Services (docs.oracle.com): confirms SuiteQL available through REST API; Oracle NetSuite Documentation, API Governance and Concurrency Limits (docs.oracle.com): confirms tiered concurrency limits and SuiteCloud Plus licensing.

When you store financial data in an ERP system, one of the most fundamental questions you can ask is: where does that data live, and what architecture separates it from everyone else's data?

NetSuite is a multi-tenant cloud ERP system. Oracle is transparent about this. Oracle's own technical documentation describes NetSuite as "a multi-tenant service offering on shared databases." NetSuite's own published materials explain the model directly: with a multi-tenant cloud model, many companies share the same instance of the software and infrastructure, though each customer's data is stored and secured separately. The separation between tenants is enforced through Oracle's software-based controls, permissions, access controls, and data-isolation rules within the shared service environment. That is Oracle's documented design for NetSuite.

Carillon's architecture is different. Each client's Carillon ERP data resides in that client's own dedicated Carillon database, in the environment the client selects, whether on-premises or in the client's own cloud environment. No other Carillon client's ERP data is stored in that database. The client's data is not one tenant's partition inside a shared Carillon application database. It is a separate database environment, chosen and controlled by the client.

Logical isolation is not inherently insecure. Oracle invests substantially in the security controls, encryption, access management, and audit infrastructure that protect shared-database environments, and NetSuite's compliance certifications reflect that investment. For many organizations, logical isolation within a managed SaaS environment is entirely sufficient, and the operational benefits of multi-tenancy, including automatic upgrades, no infrastructure management, and economies of scale, are legitimate reasons to accept the model. The shared responsibility approach works well for a large segment of the market.

The distinction matters more for some organizations than for others. Oracle's own documentation acknowledges that in a shared environment, one customer's usage pattern can affect other customers; Oracle reserves the right to throttle a customer's access if their activity may cause performance issues for other customers on the same infrastructure. Beyond performance, some organizations have specific contractual, governance, or internal policy requirements that address how ERP data is segregated from other organizations' data. For those organizations, the architectural question is not theoretical. In that conversation, "logically isolated inside a vendor-managed multi-tenant SaaS service" and "stored in the client's own dedicated Carillon database, in the environment the client selects" are not the same answer.

A dedicated Carillon database does not eliminate the need for strong security practices. Carillon clients still need appropriate user permissions, encryption, backups, monitoring, network controls, and change-management disciplines. But the starting architecture is different: the client's ERP data is in its own dedicated Carillon database, not in a shared multi-tenant service alongside the data of unrelated organizations.

For businesses where a dedicated database environment is a requirement, a preference, or simply a question they want to be able to answer clearly, Carillon's architecture provides a straightforward answer. With Carillon, in standard deployments, each client's ERP data resides in its own dedicated Carillon database, in the environment the client selects. With NetSuite, each customer's data is logically isolated within shared database infrastructure that Oracle operates and that other NetSuite customers share. Both are deliberate architectural choices. Only one of them gives clients a database of their own.

Sources: Oracle NetSuite Documentation, General Notices (docs.oracle.com): states "the Service is a multi-tenant service offering on shared databases" and documents Oracle's right to throttle customer access to protect performance for other customers; Oracle NetSuite, "What is SaaS ERP?" (netsuite.com): states "many companies share the same instance of the software and infrastructure, though each customer's data is stored and secured separately"; Oracle NetSuite, "Multi-Tenancy Defined" (netsuite.com); Oracle NetSuite, "What is NetSuite ERP and How Does It Work?" (netsuite.com).

Data ownership and data access are not the same thing. Most ERP customers never discover the difference until they actually need to act on it.

Both Carillon and NetSuite acknowledge that customer data belongs to the customer. Oracle's NetSuite Terms of Service state this directly in Section 2.12: as between Oracle and the customer, all title and intellectual property rights in and to the Customer Data are owned exclusively by the customer. Carillon's client agreement makes the same acknowledgment. On the question of who owns the data, both vendors give the same answer: you do.

The distinction is not ownership. It is control over access.

Think of it this way. You hold the title to the car. With NetSuite, the car sits in Oracle's garage, and Oracle's contract is explicit about what that means. Section 2.12 of the NetSuite Terms of Service states that the customer grants Oracle the right to host, use, process, display, and transmit Customer Data to provide the services. The data is yours. The system that stores it, manages it, and controls access to it is Oracle's. The garage is Oracle's.

If a NetSuite customer wants to extract or use its data outside NetSuite, Oracle documents the available paths: full CSV export, saved search exports, report exports, SOAP web services, and SuiteAnalytics Connect through ODBC, JDBC, or ADO.NET drivers. These are real capabilities, and many organizations find them sufficient. They are also all Oracle-defined access paths, not direct customer access to the underlying NetSuite production database.

SuiteAnalytics Connect is worth noting specifically. Oracle describes it as a service that lets customers archive, analyze, and report on NetSuite data through third-party tools using ODBC, JDBC, and ADO.NET drivers. Oracle also states that SuiteAnalytics Connect provides a read-only method for obtaining NetSuite data and cannot be used to update NetSuite data. It accesses NetSuite data through the NetSuite2.com analytics data source, not through unrestricted access to the underlying production database. It is a window Oracle provides, not a door the customer controls.

With Carillon, in standard deployments, the title and the keys come together. The customer's ERP data resides in the customer's own dedicated Carillon database, in the environment the customer selects, whether on-premises or in the customer's own cloud environment. The customer owns the data and controls the database environment where it resides. The customer can query the database directly, connect reporting tools to it, validate its contents, build integrations against it, and manage access under the customer's own security policies, without depending entirely on vendor-mediated access methods or Carillon-provided reporting tools. The car is in your driveway.

Oracle's export tools, APIs, and SuiteAnalytics Connect are legitimate capabilities and should not be dismissed. Carillon's point is not that those tools are inadequate for every purpose. The point is that they are vendor-defined access methods. They give the customer access to data through the paths Oracle provides. They do not give the customer direct control over the database environment where NetSuite stores and manages the customer's live ERP data.

Carillon believes that data ownership should be matched by practical data access. If the data is yours, you should be able to reach it in its native database environment, under your own controls, without depending entirely on a vendor-managed access layer. On the question of data ownership, both Carillon and Oracle say the customer owns the data. On the question of who holds the keys, the architectures answer for themselves.

Sources: Oracle NetSuite Main Terms of Service v061625, Section 2.12: "As between Oracle and Customer, all title and intellectual property rights in and to the Customer Data is owned exclusively by Customer" and "Customer grants Oracle the right to host, use, process, display and transmit Customer Data to provide the Services"; Oracle NetSuite Documentation, Extracting Data from NetSuite (docs.oracle.com): documents CSV export, saved searches, report exports, SOAP web services, and SuiteAnalytics Connect as the available extraction methods; Oracle NetSuite Documentation, SuiteAnalytics Connect Overview (docs.oracle.com): confirms read-only access via Oracle's Connect Service and NetSuite2.com analytics data source; Carillon client agreement.

When an approved customer invoice recording an inventory sale or return is saved in Carillon, Carillon records both the actual revenue and the actual cost of goods sold on the invoice line. Gross profit is not a separate, disconnected value that must be manually stored or synced. It is calculated directly by subtracting the actual cost from the actual revenue on that same invoice-line record. The cost is not an estimate. It reflects the inventory costing method in use for that item, whether FIFO, average cost, or standard cost. Once the invoice is posted, ordinary application users cannot silently rewrite the posted revenue or cost amounts in a way that bypasses the audit trail. Corrections are handled through proper accounting procedures rather than by altering the original historical record.

This design makes profitability reporting direct. Whether a controller wants gross profit by item, customer, salesperson, branch, project, or ship-to address, the calculation comes from a single source: the invoice-line record. Revenue minus COGS. No estimation. No fulfillment-to-invoice correlation step. For real-time Power BI reporting, the dashboard can query the same invoice-line data that holds both the posted revenue and the posted cost together.

NetSuite works differently. Oracle's own documentation categorizes its native gross profit feature on sales transactions as an estimated feature. Oracle says the Gross Profit feature estimates gross profit using estimated item costs and proposed discounts. Oracle's FAQ is even more direct: when asked whether the Gross Profit feature provides actual costs and margins or only estimated ones, Oracle answers: "Only the estimated costs and margin."

The architecture behind that distinction can also create timing and matching considerations. Oracle documents that fulfillment posts the inventory reduction and COGS impact, while billing the customer is handled through a cash sale, invoice, or other billing transaction. Oracle also documents that when Advanced Shipping is enabled, fulfillment and invoicing are independent processes, and shipments can be recorded separately from billing.

That separation matters when dates cross accounting periods. A NetSuite consulting firm has written that, for product-centric companies using sales orders, COGS is generally recognized when the item fulfillment is marked shipped, while revenue is generally recognized when the transaction is invoiced. The same firm advises customers to match invoice dates and accounting periods to the related item fulfillment dates and accounting periods, warning that accounting period mismatches must be avoided.

NetSuite does provide profitability reporting. Oracle documents a Customer Profitability Detail report that shows cost, revenue, and profit amounts categorized by customer. The issue is not that NetSuite cannot report profitability. The issue is where the native invoice gross-profit numbers originate. Oracle's documented invoice gross-profit fields are estimated fields. Carillon's invoice line stores actual revenue and actual COGS together, so actual gross profit is calculated directly from the same posted invoice-line record.

Both systems can produce profitability reports. The difference is how direct the actual invoice-level calculation is. With Carillon, actual revenue and actual COGS are already together on the invoice line. With NetSuite, Oracle's own documentation describes native invoice gross profit as estimated, while actual COGS is generated through fulfillment and inventory costing. For controllers who want real-time actual gross profit by item, customer, branch, project, salesperson, or ship-to address, that is a meaningful architectural difference.

Sources: Oracle NetSuite Documentation - Estimating Gross Profit (docs.oracle.com); Oracle NetSuite Documentation - Frequently Asked Questions about Gross Profit (docs.oracle.com); Oracle NetSuite Documentation - Using Gross Profit Fields on Transaction Forms (docs.oracle.com); Oracle NetSuite Documentation - Sales Transaction GL Impact (docs.oracle.com); Oracle NetSuite Documentation - Item Fulfillment (docs.oracle.com); Oracle NetSuite Documentation - Customer Profitability Detail Report (docs.oracle.com); Prolecto Resources - Best Practices for Automating NetSuite Invoice Generation; Carillon system architecture and invoice posting design.

Some companies want revenue and cost of goods sold tracked in the general ledger by item. Others want revenue and COGS tracked by customer, customer type, or major account relationship. There is no universal right answer. It depends on the company's chart of accounts, management reporting preferences, and internal accounting policies.

Carillon gives the accounting team that choice as part of the standard posting design. A system parameter determines whether revenue and COGS are posted by customer or by item. Organizations that need revenue from different customer types to post to separate income and COGS accounts (such as retail, wholesale, distributor, or a specific major customer with its own general ledger presentation) can configure Carillon accordingly.

The revenue and COGS accounts are stored on the customer or item record, depending on the selected posting method, and are applied when the invoice is posted. If branch accounting is enabled for that company, branch-level wildcarding further refines the posting assignment so revenue and COGS post to the appropriate branch accounts.

That flexibility does not limit profitability reporting. No matter which method is used for posting to the general ledger, Carillon profitability reports can still show revenue and COGS by the dimensions users care about, including customer, item, salesperson, branch, project, or ship-to address. Power BI can query the same posted invoice-line data directly, so management reporting does not have to match the general ledger account design exactly. And because the GL account assignment does not depend on a user-applied reporting tag, the posting is not affected by missing or incomplete segment data.

NetSuite's standard account-selection model works differently. Oracle documents that item records contain the accounting fields used for item sales and item cost. The item record includes an income account field to track item sales revenue and a COGS account field to track the cost of the item. Oracle also documents that a default COGS account is set at the company level and can be overridden per item on the item's accounting configuration. In NetSuite's standard item-account model, Oracle's documentation describes income and COGS account selection through item accounting fields, not through a standard customer-level posting parameter. Customer-based GL treatment can be handled through segmentation, reporting design, or SuiteGL customization, but that is different from Carillon's standard customer-versus-item posting option.

For customer-level segmentation, NetSuite's approach is dimensional. Class, Department, and Location segments tag transactions so they can be filtered in reports. A NetSuite partner's published implementation guidance makes this explicit, advising customers to avoid creating separate revenue accounts by customer or product type and to use Class segmentation instead. That approach carries an operational risk that account-based posting reduces: if a transaction is saved without the correct Class or segment value applied, it can appear as blank, unclassified, or be excluded from reports that filter on that dimension. The GL account still receives the posting, but customer-level visibility depends on the segment data being complete and correct.

NetSuite can go beyond its standard item-account model through SuiteGL. Oracle describes SuiteGL as a set of features that lets users customize general ledger processes, including changing line-level GL impact of transactions. Oracle's Custom GL Lines Plug-in documentation states that the plug-in changes the general ledger impact of standard and custom transactions by applying custom transaction logic that adds lines to the NetSuite GL Impact page. That is powerful functionality and it should be acknowledged. It is also customization, not the same thing as a standard accounting parameter that lets the user choose customer-based or item-based revenue and COGS posting. Oracle also documents that custom GL line impact on reports may require report customization, such as adding a Custom GL column or filter in the Report Builder. That reinforces the point: SuiteGL is a powerful customization layer, but it introduces custom reporting and audit considerations that are different from a standard posting parameter.

The distinction matters for companies whose chart of accounts genuinely requires customer-based revenue or COGS accounts. The difference is not whether NetSuite can be customized to produce a different GL impact. With SuiteGL, it can. The difference is whether customer-based versus item-based revenue and COGS posting is a standard accounting setup choice. In Carillon, it is. In NetSuite's standard model, revenue and COGS accounts come from the item, while customer-level analysis is handled through segments, reports, or customization. For organizations that want this choice built into the posting model rather than added through custom GL logic, Carillon's design is simpler, more direct, and easier to explain to auditors and financial users.

Sources: Oracle NetSuite Documentation - Account Information on Items (docs.oracle.com); Oracle NetSuite Documentation - Selecting a Default Cost of Goods Sold Account (docs.oracle.com); Oracle NetSuite Documentation - Items for Revenue and Expense (docs.oracle.com); Oracle NetSuite Documentation - SuiteGL Features Overview (docs.oracle.com); Oracle NetSuite Documentation - Custom GL Lines Plug-in Overview (docs.oracle.com); Oracle NetSuite Documentation - Custom GL Lines on NetSuite Reports (docs.oracle.com); Concentrus - Steps to Create the Chart of Accounts in NetSuite; Carillon system architecture and invoice posting design.

For companies that buy and sell high-volume, low-unit-cost items, decimal precision is not a minor technical detail. It affects how accurately unit prices, unit costs, inventory value, and cost of goods sold can be represented when transaction volumes are large and unit costs are small. This is common in businesses dealing with ingredients, packaging components, fasteners, or bulk commodities where individual unit costs are fractions of a cent.

Carillon currently supports four decimal places for unit price and unit cost across all supported inventory costing methods, including FIFO, average cost, and standard cost. Four-decimal unit-cost precision is built into the invoice-posting design, supporting more accurate gross-profit and inventory-cost reporting regardless of which costing method the company uses.

NetSuite's precision model works differently. Oracle documents that the Currency Precision field on the currency record supports only two values: 0 and 2. Oracle also states that currency decimal precision is used for inventory costing calculations to maintain consistency between inventory costing and reporting. For a company using USD, that means inventory costing calculations are tied to two decimal places.

NetSuite does document an important Standard Costing exception, and it should be acknowledged. Oracle documents that NetSuite Standard Costing is calculated with higher internal precision, and a separate Oracle documentation page confirms that standard costs are stored with high precision. But Oracle also documents that transaction amounts are rounded to the account's currency precision, usually two decimal places, and that small rounding variances can appear and accumulate when quantities are multiplied and transactions are posted. Oracle characterizes this as expected system behavior.

That distinction also matters conceptually. Standard costing is a legitimate accounting method, particularly for manufacturers that want fixed expected costs, variance analysis, and cost-control reporting. But it is not the same thing as recording actual FIFO or moving-average inventory cost at high decimal precision. Oracle's own Standard Costing workflow describes standard costs as fixed or expected costs and records variances when actual costs differ from those expectations. Oracle also documents that average costing is the default inventory costing method in NetSuite. For companies that want actual inventory cost to flow through FIFO or average costing at four decimal places, the Standard Costing exception does not address the same requirement.

The practical issue is straightforward. At two-decimal currency precision, a one-unit transaction involving a cost such as $0.0050 cannot be represented as $0.0050 in the posted currency amount. Depending on quantity, transaction timing, costing method, and reporting method, rounding to cents can create variances that accumulate across high-volume, low-unit-cost activity. Oracle's own Standard Costing documentation illustrates a case where ten single-unit receipts produce a different total inventory value than one receipt of ten units, with the difference attributed to each transaction being rounded to currency precision.

Carillon's advantage is not that NetSuite lacks every possible high-precision costing path. It is that Carillon supports four-decimal unit price and unit cost precision in the actual costing methods many companies use every day, including FIFO, average cost, and standard cost. Oracle ties most currency-based inventory costing and GL posting precision back to currency precision, which is two decimal places for USD. For companies buying or selling products priced in fractions of a cent, that architectural difference is worth understanding before choosing an ERP.

Sources: Oracle NetSuite Documentation - Currency Decimal Precision (docs.oracle.com); Oracle NetSuite Documentation - Item Costing (docs.oracle.com); Oracle NetSuite Documentation - Setting a Default Inventory Costing Method (docs.oracle.com); Oracle NetSuite Documentation - Understanding GL Impact Small Variances in Standard Costing (docs.oracle.com); Carillon system architecture and costing design.

Companies in different industries require different chart of accounts structures. A construction company needs job cost accounts, retention receivable, overbillings, underbillings, and work in progress. A retail company needs accounts for shrinkage, gift card liabilities, and point-of-sale cash variances. A commercial real estate company needs accounts for tenant security deposits, deferred rent, and straight-line rent adjustments. Beyond industry differences, some companies use branch accounting and need branch-level revenue, expense, and balance sheet accounts built into their chart of accounts structure. Other companies in the same system do not use branch accounting and have no need for those accounts. Requiring them to share a common account structure means one company carries accounts that are irrelevant to its operations, or the shared structure is compromised to accommodate the simpler entity.

In Carillon, each company operates with its own independent chart of accounts. There is no shared master chart of accounts that every company must use for transaction posting. During initial setup, an administrator can copy another company's chart of accounts as a starting point if consistency is desired. But that is a convenience, not a requirement. Two companies in the same Carillon installation can use entirely different account numbering schemes, different account structures, and different levels of detail. A company that uses branch accounting can have that structure built directly into its chart of accounts. A company in the same installation that does not use branch accounting does not need those accounts and is not required to carry unused accounts or segments to accommodate any other company.

Consolidation reporting across Carillon companies does not require the companies to share a common chart of accounts structure. Carillon's Financial Statement Generator uses a position-based design: for each line of each financial statement, you specify exactly which account balances belong in that position. Each company can have its own statement definition mapping its own accounts to the appropriate positions. Consolidated statements work across companies with different underlying account structures because the consolidation is handled at the statement definition level, not by requiring account number uniformity across entities.

NetSuite OneWorld is designed differently. Oracle's OneWorld Overview states that OneWorld uses a single chart of accounts as well as subsidiary-specific accounts to prepare consolidated and subsidiary financial statements. Oracle also states that all subsidiaries generally use the same chart of accounts and fiscal periods, while country-specific accounts can be added for statutory or internal reporting requirements. Oracle also documents that NetSuite maintains a single listing of accounts on the Chart of Accounts page.

NetSuite does provide important flexibility inside that model. Accounts can be restricted to specific subsidiaries so that not every entity sees every account. Oracle documents accounting contexts for local GAAP or statutory chart-of-accounts reporting needs, and also states that accounting contexts can support unique company needs. Even so, accounting contexts provide alternate account names and numbers for reporting and localization purposes; they are a display layer, not the same as giving each operating company a completely independent transaction-posting chart of accounts. The underlying GL transaction still posts to the central account regardless of which accounting context is applied. Oracle also documents chart-of-accounts mapping for secondary accounting books in Multi-Book Accounting. Those are real capabilities and should be acknowledged.

Oracle's own OneWorld documentation makes the design assumption explicit: OneWorld provides the most value when all subsidiaries have similar business processes and generally use the same chart of accounts and fiscal periods. A NetSuite partner's published implementation guidance reinforces this, advising customers that it is best practice to allow all subsidiaries to share GL accounts and to avoid creating unique accounts for each subsidiary. That is sound guidance for a homogeneous business with similar operations in multiple locations. It becomes a more difficult design challenge when the companies in the system operate in different industries or use fundamentally different accounting structures such as branch accounting versus non-branch accounting.

Carillon's independent chart of accounts design means each company can structure its accounts the way that company's accountants, managers, and auditors expect to see them, without affecting any other company in the system. NetSuite OneWorld provides subsidiary-specific accounts, accounting contexts, and chart-of-accounts mapping tools as flexibility within its central model. For organizations that operate multiple companies with genuinely different accounting structures, Carillon's company-by-company chart of accounts combined with its position-based Financial Statement Generator is a simpler and more direct solution.

Sources: Oracle NetSuite Documentation - OneWorld Overview (docs.oracle.com); Oracle NetSuite Documentation - Chart of Accounts Management (docs.oracle.com); Oracle NetSuite Documentation - Chart of Accounts Mapping (docs.oracle.com); Oracle NetSuite Documentation - Accounting Contexts (docs.oracle.com); Concentrus - Steps to Create the Chart of Accounts in NetSuite; Carillon system architecture, multicompany design, and Financial Statement Generator.

In many procurement scenarios, the party who ships the goods and the party who receives payment are not the same. A buying cooperative may negotiate pricing with a manufacturer on behalf of its members. A farmer may purchase tractor tires through a cooperative that has a purchasing agreement with a tire supplier. The purchase order goes to the tire supplier. The payment goes to the cooperative. Those are two distinct business relationships, and a purchasing system should be able to track them separately.

Carillon makes that distinction a standard part of the data model. In Carillon, a vendor is who you pay. A supplier is who you issue the purchase order to. These are separate records with a many-to-many relationship. A single item can have multiple suppliers, one of which is designated as the primary supplier. Within supplier maintenance, each supplier can be associated with multiple vendors, and a supplier price file exists for each supplier/vendor combination, including effectivity dating on pricing.

That means the price Carillon applies to a purchase order can reflect both the specific supplier shipping the goods and the specific vendor receiving the payment. When a purchase order is created, the user specifies both the supplier and the vendor. Those can be the same party or different parties, supporting buying-group, cooperative, and purchasing-agent arrangements as part of the standard purchasing design. Carillon's architecture allows the accounts payable liability to be directed to a completely different legal entity than the one receiving the purchase order, as a standard, non-customized feature.

Carillon also uses that multi-supplier structure to support purchasing decisions. At purchase order creation time, if a less expensive supplier is available for the item being ordered, Carillon notifies the user natively on the PO entry screen. The buyer can see whether the current supplier selection is the lowest-cost option before the order is placed.

NetSuite's standard procurement model works differently. Oracle documents a Multiple Vendors feature that lets an item be associated with more than one vendor. For each vendor, users can track information such as the vendor's item code and purchase price, and one vendor can be marked as preferred. Oracle states that the preferred vendor appears on purchase orders by default.

That is useful functionality, and it should be acknowledged. But it is still vendor-based. In NetSuite's standard purchasing flow, the purchase order, item receipt, vendor bill, and payment process are organized around the vendor relationship. Oracle's documentation describes associating vendors with items, choosing a vendor on the purchase order, using that vendor's currency for the purchasing process, and then validating the vendor bill against the purchase order and item receipt. Oracle's standard purchasing documentation reviewed for this reason does not show a native standard purchase order structure where the supplier receiving the purchase order and the vendor receiving payment are separate parties on the same PO.

That distinction matters for businesses that operate through buying cooperatives, purchasing groups, manufacturers' representatives, or other multi-party procurement arrangements. NetSuite can associate multiple vendors with an item and can default the preferred vendor onto purchasing forms. Carillon goes further by separating the supplier relationship from the vendor/payables relationship as part of the standard data model.

With Carillon, the user can say: "Order this item from this supplier, using the price file tied to this supplier/vendor relationship, but pay this vendor." In NetSuite's standard purchasing flow, the item is associated with vendors, the purchase order is issued to a vendor, and the vendor bill is validated against the purchase order and item receipt. Separating the ordering party from the pay-to party would generally require customization, integration, or a process workaround outside that standard flow.

Sources: Oracle NetSuite Documentation - The Multiple Vendors Feature (docs.oracle.com); Oracle NetSuite Documentation - Associating an Item With Multiple Vendors (docs.oracle.com); Oracle NetSuite Documentation - Entering a Purchase Order (docs.oracle.com); Oracle NetSuite Documentation - 3 Way Match Vendor Bill Approval Workflow (docs.oracle.com); Carillon system architecture and purchasing design.

For a controller responsible for closing the books, inventory costing is not just about getting the final answer eventually. It is about knowing whether inventory, COGS, and freight-related variances are posted in a way that keeps the close stable and explainable.

Carillon handles freight differences through the purchasing and three-way-match process. When inventory is received, the inventory account is debited based on the received inventory cost. When the vendor invoice is processed, Carillon performs a three-way match and calculates cost, quantity, and freight variances. If freight was estimated on the purchase order or at receiving, the actual freight on the invoice is compared to that estimate and the difference is posted to the freight variance account. If freight was not estimated, the full freight amount is posted to the freight variance account at invoice processing time.

That means Carillon does not need to reopen the inventory receipt cost layer when the freight bill arrives later. The inventory costing subledger remains tied to the inventory control account, and the variance accounts capture the difference between what was capitalized into inventory and what was billed later. For period close, that distinction matters: late freight does not require the controller to restate earlier inventory costs or revisit COGS on items that may already have been sold.

NetSuite can include freight in inventory value through its Landed Cost feature. Oracle documents that landed costs such as freight, duty, taxes, insurance, and handling can be added to the asset value of inventory and contribute to COGS and profitability. That is legitimate and useful functionality. NetSuite's 2026.1 release also introduced automated landed cost validations and rule-based processing for greater control and compliance during PO receipt.

The timing challenge remains for companies using FIFO or average costing. Freight costs are often not known at the time inventory is received. Oracle's own landed-cost documentation says freight charges are commonly not known before the freight vendor's bill is received. If landed costs are not known at receipt, Oracle says an estimated amount can be entered; in another documented example, the freight bill arrives later, the user enters a freight vendor bill, then edits the original item receipt to identify the freight charge as landed cost. It is worth noting that NetSuite's standard costing method handles this differently -- landed cost creates a variance against the standard cost rather than modifying the cost layer. The timing issue discussed here applies specifically to FIFO and average costing users.

That later receipt edit is the accounting-control issue for FIFO and average costing. When landed cost is added later by editing the receipt, that later change can alter the item's costing history and trigger inventory costing recalculations. If related goods were sold after the receipt date, the recalculation can affect downstream COGS, which creates a dependency between the arrival of the freight bill and the finality of inventory costing. Oracle documents this directly: inventory costing values need to be recalculated each time there is a change to the costing history of a particular item, and if the accounting period is closed while inventory costing calculations are still in progress, it can affect costing accuracy and cause errors.

Both systems can account for freight. The difference is the control model. Carillon treats the freight difference as a variance during invoice processing, preserving the original inventory costing relationship and keeping the close easier to reconcile. NetSuite's landed-cost model can capitalize freight into inventory, but for FIFO and average costing users when freight cost is not known at receipt, the edit-receipt workflow can trigger costing recalculations with downstream COGS impact. For controllers using FIFO or average costing, Carillon's approach is simpler, more predictable, and less dependent on landed-cost timing discipline.

Sources: Oracle NetSuite Documentation - Landed Cost Overview (docs.oracle.com); Oracle NetSuite Documentation - Landed Cost Billed Separately With a Cost Estimate (docs.oracle.com); Oracle NetSuite Documentation - Landed Cost Billed Separately With Advanced Receiving (docs.oracle.com); Oracle NetSuite Documentation - Inventory Costing Recalculations (docs.oracle.com); Oracle NetSuite Documentation - Inventory Costing Recalculations on Inventory Adjustments (docs.oracle.com); Oracle NetSuite Documentation - Accounting for Received Purchase Orders (docs.oracle.com); Oracle NetSuite Documentation - Vendor Bill Variances (docs.oracle.com); Oracle NetSuite Resource Center - New NetSuite 2026.1 Inventory, Pricing, Connector, and Warehouse Management AI Capabilities Help Optimize Business Operations (netsuite.com); Carillon system architecture and purchasing design.

For importers and international distributors, the true cost of inventory is not the supplier's invoice price. It is that price plus every cost incurred moving the product from the supplier's dock to the final warehouse destination. When a shipment involves multiple suppliers, multiple consolidators, and multiple legs of freight -- each applying to a different subset of products -- allocating those costs accurately and getting them into the FIFO cost layers of the right items is a complex accounting requirement that most ERP systems cannot handle natively.

Consider a realistic example. A beverage distributor in Bermuda places orders with three California wineries and one whisky supplier. The three wineries ship to a California consolidator who fills half a container. That half-container travels to Boston, where a second consolidator fills the container with the whisky. The full container then makes the ocean voyage to Bermuda. The cost components include the California consolidator's fees, the freight from California to Boston, the Boston consolidator's fees, the ocean freight, the ocean insurance, the harbor freight at the Bermuda port, and the freight from the port to the final warehouse. Some of these costs apply only to the wine. Some apply only to the whisky. Some apply to both. The user may also define additional cost components specific to their business.

Carillon handles this through its Container Processing function, which is what Carillon calls Landed Cost. At the time of Container Receiving, all cost components -- including each leg of freight, each consolidator's fees, ocean freight, ocean insurance, harbor fees, delivery to the final warehouse, and any user-defined cost components -- are allocated to the appropriate products and flow directly into the FIFO cost layers for each item. The California consolidator's fees are not attributed to the whisky. The Boston-to-Bermuda ocean freight is attributed to both the wine and the whisky in the appropriate proportions. Each bottle of Napa Chardonnay received carries its precise share of every cost component that applied to its journey. That is what it actually cost to land that bottle in the warehouse, and that is what COGS reflects when it is sold.

NetSuite provides meaningful landed cost functionality. Oracle documents landed costs on item receipts, vendor bills, and inbound shipments, including allocation by quantity, value, or weight. Oracle also documents Inbound Shipment Management, which can group items from multiple purchase orders into a single shipment and apply landed costs across the shipment or to specific line items. For straightforward single-leg shipments, that capability is useful and should be acknowledged. What NetSuite describes as its Landed Cost feature is functionally similar to what Carillon calls Inventory Receipts -- receipt-level cost allocation for straightforward shipments. Carillon's Container Processing addresses a more complex and specialized requirement.

The multi-leg, multi-consolidator scenario is where Carillon's Container Processing goes beyond NetSuite's documented standard landed-cost model. Oracle's documentation describes allocation within receipts, vendor bills, inbound shipments, and transaction lines, using methods such as quantity, value, or weight. There is no documented native structure for tracking multiple legs of a journey where each leg applies to a different subset of products and generates its own cost components that must be allocated only to the products that traveled that leg. A key documented constraint reinforces this: Oracle states that a landed cost vendor bill can be sourced to only a single item receipt. If the California consolidator's fee needs to be allocated across three separate wine receipts from three separate wineries, that requires the user to select Manual as the source and enter the cost separately on each receipt. While NetSuite allows for the creation of custom landed cost categories, the standard automation is designed to apply those costs to the shipment as a whole. Carillon's Container Processing differs by allowing cost components to be tied to specific journey legs, ensuring that a California consolidator's fee is never attributed to goods that did not travel that leg.

A distributor handling complex multi-leg international shipments in NetSuite may need detailed manual allocation, multiple shipment or receipt records, SuiteScript customization, or a specialized process design to approximate what Carillon handles as a standard Container Processing workflow.

For importers and international distributors where landed cost accuracy directly drives gross margin reporting, pricing decisions, and inventory valuation, Carillon's Container Processing provides a level of journey-leg precision and automation that NetSuite's standard landed cost tools are not designed to match.

Sources: Oracle NetSuite Documentation - Inbound Shipment Management (docs.oracle.com); Oracle NetSuite Documentation - Using Inbound Shipment Management (docs.oracle.com); Oracle NetSuite Documentation - Landed Cost Overview (docs.oracle.com); Oracle NetSuite Documentation - Entering Landed Cost on a Transaction (docs.oracle.com); Oracle NetSuite Documentation - Landed Cost Billed Separately With Advanced Receiving (docs.oracle.com); Oracle NetSuite Documentation - Landed Cost Allocation per Line (docs.oracle.com); Carillon system architecture and Container Processing design.

For distributors, especially in industries such as chemical distribution, rebates are not side calculations. Vendor rebates affect the true cost of inventory. Customer rebates affect the true profitability of the sale.

Carillon treats those rebates as part of the cost and margin picture. Purchase rebates flow into inventory costing, including FIFO layers. When the product is sold, the rebate-adjusted cost flows through COGS. Sales rebates flow into COGS and affect profitability reports. The result is that Carillon's inventory value, cost of goods sold, and gross profit reporting reflect the economic reality of the rebate.

NetSuite handles rebates through its Rebates and Trade Promotions SuiteApp. Oracle documents meaningful rebate functionality in the SuiteApp, including rebate agreements, accruals, claims, disbursements, settlements, and support for both sales and purchase transactions. That functionality should be acknowledged.

The architectural difference is where the rebate lands. Oracle's documentation for the Rebates and Trade Promotions SuiteApp instructs users to utilize non-inventory or other-charge items for settlements, and states directly: "Ensure that settlements do not impact your inventory." Carillon's approach differs by integrating purchase rebates directly into inventory costing, including FIFO layers, so the reduction in cost stays with the product until it is sold.

This distinction matters because accounting guidance under ASC 705-20 presumes that cash consideration received from a vendor is a reduction of the price of the vendor's products, unless an exception applies. PwC's Inventory Guide states that probable and estimable rebates or refunds should be considered in valuing inventory. A settlement workflow that keeps rebate settlements outside inventory does not naturally produce that inventory-cost result by itself; it may require additional accounting entries, configuration, or close procedures.

Both systems can track rebates. The difference is whether rebates are integrated into inventory costing and profitability reporting. In Carillon, they are. In NetSuite's documented Rebates and Trade Promotions SuiteApp settlement workflow, rebates are settled through non-inventory or other-charge items that Oracle instructs should not impact inventory. For distributors where rebates materially affect margin, that is a meaningful accounting and reporting difference.

Sources: Oracle NetSuite Documentation - Rebates and Trade Promotions (docs.oracle.com); Oracle NetSuite Documentation - Rebate Types Used in Rebates and Trade Promotions (docs.oracle.com); Oracle NetSuite Documentation - Creating Accounting Item Records for Rebates and Trade Promotions (docs.oracle.com); PwC Viewpoint, Inventory Guide, Section 1.5.4 - Vendor Rebates, ASC 705-20; Carillon system architecture and rebate processing design.

Branch accounting means more than running a report by location. In a multi-branch company, an income statement is only meaningful if revenue and the related cost of goods sold are assigned to the same reporting unit using the same rule every time. If revenue appears in Dallas and the related COGS appears in Chicago, the company-level income statement may still be correct, but neither branch income statement reliably measures branch profitability. Assigning revenue and related costs to the same reporting unit under a consistent policy is the matching principle applied at the branch level -- and it requires more than flexible reporting. It requires an enforced posting rule.

Consider a common example. A salesperson in the Dallas branch enters a sales order. The inventory ships from the Chicago branch because Chicago has the stock. The customer may be assigned to another branch, and the ship-to address may be assigned to another. Which branch gets credit for the revenue? Which branch receives the related COGS?

In Carillon, that question is answered by a system parameter that is enforced consistently across applicable transactions. The company defines the branch-credit rule once -- such as the ordering salesperson's branch, the ship-to branch, the customer's assigned branch, the sales order location, or the user's branch. Carillon then applies that rule when posting revenue and COGS. Because Carillon records revenue and COGS together on the invoice line, both amounts follow the same branch decision.

Carillon also supports segment-based reporting through its Financial Statement Generator. So this is not a choice between branch accounting and reporting flexibility. Carillon supports flexible reporting, but it also supports branch accounting at the posting level. Branch can be part of the accounting structure, and the system enforces the branch-credit policy before the financial statement is produced.

NetSuite documents a different model. Oracle documents financial reporting by Location, Class, Department, subsidiary, and custom segments. Oracle's Income Statement and Financial Report Builder documentation describes filtering, grouping, and presenting financial statement data by dimensions such as class, department, location, and subsidiary. Oracle also documents per-line locations and classifications on transactions. That is useful location-based and segment-based reporting functionality.

But in the Oracle NetSuite documentation reviewed for this reason, we found no documentation claiming that NetSuite supports Branch Accounting as a named feature, and no documentation of an enforced branch-credit posting rule that assigns revenue and related COGS to the same branch under one company-defined policy.

That omission is understandable. NetSuite's documented model is based on transaction classifications. If revenue and related COGS depend on Location, Class, Department, or custom segment values carried on separate posting transactions, then branch-level profitability depends on those segment assignments being complete, correct, and consistent.

The problem becomes obvious when the selling branch and shipping branch differ. Oracle documents Advanced Shipping as allowing fulfillment and billing to be handled separately. Oracle also documents Automatic Location Assignment as a way to assign fulfillment locations to sales order lines. Those features answer fulfillment and reporting questions. They do not document a branch-accounting control that says: when the selling branch and shipping branch differ, assign both revenue and related COGS to the same branch under one enforced rule. When revenue posts to one location and related COGS posts to another, the matching principle is not satisfied at the branch level. The company-level income statement may still balance, but neither branch income statement can be relied upon to measure that branch's actual profitability.

Carillon's branch accounting model is direct. The branch-credit rule is defined once. The system enforces it. Revenue and COGS follow the same branch decision. NetSuite documents location-based and segment-based financial reporting, but we found no Oracle documentation claiming that NetSuite supports Branch Accounting as an enforced posting feature. For companies that rely on branch income statements to manage performance, that difference matters.

Sources: Oracle NetSuite Documentation - Income Statement Report (docs.oracle.com); Oracle NetSuite Documentation - Financial Report Builder (docs.oracle.com); Oracle NetSuite Documentation - Using Per-Line Classifications (docs.oracle.com); Oracle NetSuite Documentation - Setting a Location on a Transaction (docs.oracle.com); Oracle NetSuite Documentation - Configuring Per-Line Locations for Transactions (docs.oracle.com); Oracle NetSuite Documentation - Advanced Shipping (docs.oracle.com); Oracle NetSuite Documentation - Automatic Location Assignment (docs.oracle.com); Carillon system architecture, Financial Statement Generator, and branch accounting design.

Sales order entry is where efficiency either happens or disappears. A customer is on the phone. The order taker needs purchase history, pricing, availability, ship-to information, tax, delivery dates, related purchase orders, related production orders, and sometimes a quote or order acknowledgement sent immediately. The issue is not whether the ERP can eventually store the information. The issue is how much navigation it takes while the customer is waiting.

Carillon Sales Order Entry is designed around one working window and one Save. From the Sales Order Entry window, an authorized user can create quotes and orders, copy previous orders or quotes, convert a quote into an order with one click, create new customers, items, and ship-tos, check Available to Sell quantities as of the promise date, automatically price lines using contract pricing and discounts, calculate sales tax, add notes, view customer and item notes, see item pictures, draw item diagrams, and configure the first level of a bill of materials or kit. The user can also email a quote or order acknowledgement directly from the Sales Order Entry window by choosing File / Send while still on the phone with the customer.

The purchase-history example shows the difference clearly. In Carillon, unlimited customer purchase history is available inside the Sales Order Entry window. The user can review history by date, such as "what did this customer buy the last three times?", or by item, such as "what did this customer pay for this item the last six times they bought it?" That is exactly the kind of question that comes up during a live order. In Carillon, the answer is available without leaving the order.

Carillon also lets the user continue the operational work from the same order-entry flow. The user can create one or more purchase orders for items on the sales order, create one or more production orders, ship each line to multiple ship-tos, identify the warehouse, record payments, record down payments that post to deferred revenue, and assign multiple salespeople with split commissions. The point is not just that Carillon has those features. The point is that the user can complete the work in one order-entry workspace and commit the transaction with one Save.

NetSuite's documented model is different. Oracle documents sales order entry as a browser-page transaction process: the user creates a sales order, selects a customer, enters items, shipping, billing, payment, accounting, relationship, and communication information, and then saves the transaction. NetSuite has useful capabilities, including customer records, Customer 360, sales reports, item availability tools, special-order purchasing, and related transactions. But Oracle's documentation places many related activities in separate browser pages, reports, popups, customer pages, or follow-on transaction processes.

For example, Oracle documents Customer 360 as a separate customer page that collects customer information from different areas of NetSuite, including purchasing trends and related information. That is useful, and it should be acknowledged. But it is still a customer page, not the active sales order entry page. Oracle also documents customer records as tracking transaction history and items purchased, and separately documents a Sales Orders by Customer Detail report showing approved sales orders and return authorizations by customer for a selected date range.

Availability is another example. Carillon checks Available to Sell as of the promise date inside Sales Order Entry. NetSuite's Available to Promise documentation describes checking availability through an item availability popup on the transaction, and Oracle also documents a separate Check Item Availability page where users select location, item, and quantity. Those are real capabilities, but they are additional interactions outside the main order-entry flow.

Both systems can process sales orders. The difference is efficiency. Carillon is designed so the order taker can stay in one working window, answer the customer's questions, review detailed purchase history, create related records and documents, email the quote or order acknowledgement, and Save once. NetSuite's documented workflow often requires the user to move among browser pages, customer pages, reports, popups, and related transactions to assemble the same working context. For high-volume order entry, those extra navigation steps are not cosmetic. They turn into minutes per order, more chances to lose context, and more opportunities for mistakes.

Sources: Carillon ERP, Sales Order Entry; Oracle NetSuite Documentation - Creating Sales Orders (docs.oracle.com); Oracle NetSuite Documentation - Customer 360 (docs.oracle.com); Oracle NetSuite Documentation - Customers (docs.oracle.com); Oracle NetSuite Documentation - Sales Orders by Customer Detail Report (docs.oracle.com); Oracle NetSuite Documentation - Checking Item Availability on Transactions (docs.oracle.com); Oracle NetSuite Documentation - Checking Item Availability (docs.oracle.com).

We admit it.

NetSuite is much better at marketing and advertising than Carillon. They have Oracle's global brand, a huge partner network, big advertising reach, and the kind of name recognition that makes people nod before they know what the software actually does.

Sources: We have eyes.

Carillon provides an Issue Inventory window that allows inventory to be issued to a job, optionally using barcoding, from any inventory location, including a warehouse or service van. This process charges the inventory cost to the job. Under Carillon percentage-of-completion accounting, that cost immediately affects job profitability and recognized revenue.

Oracle NetSuite's public documentation describes several related inventory and project workflows.

Oracle documents an Inventory Adjustment process where a user can select a customer or job when the adjustment is a job-related cost that is not billed as a line item. Oracle also documents item fulfillments from sales orders for inventory items as a cost source in the NetSuite Project Profitability Report. For NetSuite's Project Cost-to-Cost Percent Complete SuiteApp, Oracle states that actual cost can be based on Project Profitability or Custom Criteria.

Based on the public Oracle documentation we reviewed, we were unable to verify the NetSuite workflow that performs the complete Carillon sequence: issuing inventory directly from a warehouse or service vehicle to a job or task, reducing inventory, charging the cost to the job, reflecting the cost in project profitability, and including the cost in percentage-of-completion revenue recognition.

Companies evaluating this requirement should verify directly with Oracle NetSuite how their licensed NetSuite configuration handles inventory issues to projects, whether those transactions appear in the NetSuite Project Profitability Report, and whether they are included in percentage-of-completion revenue recognition calculations.

Sources: Oracle NetSuite Documentation — Entering an Inventory Adjustment (customer/job field for job-related costs); Oracle NetSuite Documentation — Project Profitability Report (item fulfillments from sales orders as a Supplier cost source); Oracle NetSuite Documentation — Creating a Project Cost Percent Complete Rule (Actual Cost Basis: Project Profitability or Custom Criteria).

Units of measure are not always interchangeable by a single universal formula. Some businesses buy, stock, sell, price, or report the same item using different kinds of units, and the conversion depends on the item's physical characteristics.

For example:

• A fabric distributor may buy fabric by the linear yard but sell or price it by the square yard. One linear yard of 54-inch-wide fabric equals 1.5 square yards, while one linear yard of 72-inch-wide fabric equals 2 square yards.
• A lumber distributor may sell material by the linear foot but also need board-foot calculations. A 2x4 and a 2x12 do not convert from linear feet to board feet at the same rate.
• A sheet-goods distributor may buy or sell by the sheet but report, price, or quote by square feet. One 4x8 sheet equals 32 square feet, while one 5x10 sheet equals 50 square feet.
• A flooring, wallcovering, or insulation distributor may buy by the roll but sell, price, or report by square feet or square yards, where the roll width and roll length are properties of the specific item.
• A pipe distributor may sell pipe by the linear foot but also need to price, purchase, ship, or analyze it by weight. Three feet of one pipe item may weigh 2 pounds, while three feet of another pipe item may weigh 11 pounds. The conversion is not a universal feet-to-pounds conversion. It depends on the specific pipe.

In each case, the conversion is not simply a global unit conversion like inches to feet, feet to yards, pounds to tons, or square feet to square yards. The conversion depends on the item. That item-specific conversion factor needs to live in the ERP so purchasing, receiving, sales, pricing, costing, inventory valuation, fulfillment, and reporting all use the same rule automatically.

Carillon supports both levels of unit of measure conversion natively. Global conversions — such as 12 inches in a foot, 3 feet in a yard, or 2,000 pounds in a ton — can be defined once and used wherever that standard conversion applies. Item-specific conversions — such as the square yards per linear yard of a specific fabric, the board feet per linear foot of a specific lumber item, the square footage of a specific sheet-good item, or the weight per linear foot of a specific pipe item — are defined at the item level.

When a salesperson enters an order, Carillon can use the correct item-specific conversion automatically. When purchasing receives the item in a different unit, Carillon can convert it using the item's own conversion factor. Pricing, costing, inventory valuation, and reporting work from the same item-level data, without manual calculation and without the risk of using the wrong conversion rate for the wrong product.

NetSuite's documented Multiple Units of Measure feature is built around fixed-ratio Units Types. Oracle describes setting up a Units Type, assigning one base unit, and defining the other units in that type by their conversion rate to the base unit. Oracle gives examples such as a Length Units Type with Inch, Foot, and Yard, where Foot and Yard are defined in relation to the base unit.

Oracle also states that the Units Type assigned to an item determines which purchase, stock, and sale units can be used for that item. The stock unit is used for inventory counts and average cost, the purchase unit defaults on purchase transactions, and the sale unit defaults on sales transactions.

That documented architecture appears well-suited for fixed conversions within a Units Type. The critical architectural question for companies with item-specific requirements is different: can the system natively handle variable, cross-dimensional conversions at the item level — without SKU-specific Units Types, SKU-specific units, scripting, or customization — and use those conversions consistently across purchasing, receiving, sales, costing, inventory valuation, fulfillment, and reporting?

Carillon was built to handle that requirement. NetSuite may be configurable or customizable for specific scenarios, and companies evaluating this requirement should verify directly with Oracle NetSuite how their licensed configuration handles item-specific cross-dimensional unit conversions. The distinction is not whether an item's physical attributes — such as weight, width, length, area, or thickness — can be stored in a field. The distinction is whether those item-specific attributes automatically drive unit conversion as a native component of the core ERP workflow for buying, stocking, selling, costing, valuing, fulfilling, and reporting inventory.

Sources: Oracle NetSuite Documentation — Multiple Units of Measure; Oracle NetSuite Documentation — Setting Up Units of Measure (Units Type architecture: single base unit, all conversions relative to that base); Oracle NetSuite Documentation — Assigning Units of Measure to Items; Oracle NetSuite Documentation — Entering Item and Cost Details.

Purchase orders are legal and operational commitments. When the terms of that commitment change — a quantity is revised, a delivery date shifts, a line item is added or removed, or pricing is corrected — both the buyer and the supplier need to know which version is current.

That becomes especially important when a purchase order changes more than once. If a supplier receives several revised copies of the same purchase order, the process needs to make clear which revision controls, what changed, and how receiving should be handled when the packing list still references the original PO number.

Carillon handles that with formal purchase order revision control. When a revision is made to an approved purchase order, Carillon creates a new purchase order record in the database for the revised version. The vendor-facing purchase order number remains the original purchase order number, so the vendor always sees the same PO number regardless of how many revisions occur. Internally, Carillon tracks the original PO number, the latest PO number, and the revision number, preserving the relationship between the original commitment and each revised version.

This gives the supplier a stable reference while preserving formal revision control inside the ERP. The change order can be communicated to the supplier by fax, email, or print, using the supplier's own item IDs and descriptions where applicable. Carillon's public purchase order documentation describes supplier communication as a core purpose of purchasing: communicating purchase orders, change orders, and cancellation orders to suppliers, using supplier item IDs and descriptions when appropriate. It also lists change orders as purchase order processing functionality.

Carillon also carries that revision logic into receiving. When goods arrive, the supplier's packing list normally references the original vendor-facing PO number. During Inventory Receipts, when the original PO number is entered, Carillon automatically retrieves the latest revision of that purchase order and applies the receipt against the current approved version. This architecture ensures the warehouse receives against the most recently approved commitment, even when the physical paperwork in the box points to the original PO number.

Oracle's documented NetSuite workflow for editing a purchase order is different. Oracle instructs the user to find the purchase order, click Edit, make the necessary changes directly on the purchase order, and — if the vendor has received the earlier version — state that the purchase order is a revised order in the Vendor Message field. Oracle then instructs the user to check the appropriate box to print, email, or fax a copy of the revised purchase order to the vendor and save the transaction.

NetSuite does keep internal change history. Oracle documents transaction history, system notes, audit trail functionality, and System Notes v2 for tracking record and transaction changes, including who made changes, when changes occurred, and old and new values for changed fields.

That internal audit history is useful, but it is not the same thing as a supplier-facing purchase order change order process. In Oracle's documented workflow for editing an existing purchase order, the revised document is the modified purchase order sent again to the vendor. The documentation does not describe generating a distinct supplier-facing change order document, assigning a purchase order revision number, or maintaining an original-PO/latest-revision relationship that automatically directs receiving to the current approved revision when the vendor references the original PO number.

Oracle does document NetSuite Change Orders in the Supply Planning Workbench, but that documentation concerns suggested supply plan changes after firmed and released orders, rather than a structured supplier-facing procurement workflow for revising already-issued purchase orders.

For organizations where purchase orders are high-value, multi-revision commitments — construction, manufacturing, government contracting, project-based procurement, or any business with long supplier relationships and complex purchasing activity — the difference matters. System notes help answer audit questions after the fact. Formal revision control helps the buyer, supplier, receiving department, and accounting department stay aligned on which version of the commitment controls.

Companies evaluating this requirement should verify directly with Oracle NetSuite whether their licensed configuration supports supplier-facing purchase order change orders with revision numbers, original-PO/latest-revision tracking, automatic receiving against the latest revision, before-and-after change detail, approval controls, and structured supplier communication, and whether that capability is included natively or requires SuiteScript, SuiteFlow, a SuiteApp, or a third-party procurement add-on.

Sources: Oracle NetSuite Documentation — Editing a Purchase Order; Oracle NetSuite Documentation — Reviewing Transaction History; Oracle NetSuite Documentation — System Notes and System Notes v2; Oracle NetSuite Documentation — System Notes v2 Overview; Oracle NetSuite Documentation — Change Orders (Supply Planning Workbench); Carillon ERP — Purchase Order Processing. Documentation reviewed May 7, 2026.

Efficiency in an ERP system often comes down to how quickly a user can find a specific record (a customer, an item, a voucher, or another lookup value) without leaving the current workflow. Carillon's popups are consistent, high-performance tools that allow every user to find data the way they want to see it.

Every popup in Carillon works the same way: as the user types partial values into the filter bar above any column, the rows are filtered. Selecting from millions of rows is very efficient. The filter bar supports SQL Server's LIKE syntax for pattern matching. Sorting by multiple columns in ascending or descending order is available by clicking the column headings.

Popups are user-configurable. Individual users can choose which columns to display and set their own column widths without administrator assistance. Site administrators define the site-level popup defaults, but users can override the site definition by adding or removing columns. When popups are used on transactions, users can toggle between approved transactions, unapproved transactions, or both, and can filter transactions by specific branches.

NetSuite provides several native tools for finding records, including dropdown autocomplete, popup lists, popup auto suggest, popup search links, global search, custom list views, and saved searches. Oracle's documentation says NetSuite dropdown fields can autocomplete when users type the first letters of a value. For larger lists, NetSuite can display a popup list instead of a dropdown, controlled by the user's Maximum Entries in Dropdowns preference. Oracle also says that users can type letters and press Tab to open a popup list containing records that begin with those letters, and that popup auto suggest displays matching records after the user types three or more letters.

For more detailed lookup searches, Oracle documents popup search links that open a separate search window. The user enters criteria, clicks Submit, reviews the matching results, and selects the desired record. NetSuite also has broader search tools outside the field-selection popup workflow. Global search can find records from a single keyword query, supports the % wildcard, supports record-type prefixes using : or ^, starts after three characters, and shows suggested matches by default. Custom list views can change the columns displayed on list pages, select footer filters, and choose a sort field. Saved searches can include advanced filters and results display options, and Oracle documents that saved searches can be used as list views, sublist views, dashboard views, and preferred search forms.

The difference is that Carillon puts advanced lookup capabilities directly into the popup itself. Based on Oracle's documented NetSuite popup-list workflow, NetSuite does not describe per-column live filtering, SQL-style pattern matching inside the popup, multi-column popup sorting, transaction approval-status filtering, branch filtering, or end-user hide/show column control within the field-selection popup itself. Comparable NetSuite capabilities are handled through separate workflows such as popup search windows, global search, saved searches, preferred search forms, and custom list views, rather than through the same in-popup value-selection experience.

Sources: Oracle NetSuite Documentation: Popup and Dropdown Lists (autocomplete, popup lists, Maximum Entries in Dropdowns preference, popup auto suggest, popup search links, popup search workflow).

Efficient billing often requires the flexibility to change how an invoice is handled based on the product being sold, not only the customer being billed. This is especially important in industries where different goods (such as diesel, lubricants, packaged goods, bulk products, or regulated products) may require different invoice layouts or payment terms.

Carillon handles this through customer defaults with item-level overrides. Each customer can have a default invoice format and default payment terms, such as Net 30. When appropriate, the item being sold can override those customer defaults. If a customer buys diesel, Carillon can apply one invoice format and one set of payment terms. If the customer buys a case of oil, Carillon can apply a different invoice format and different payment terms. If one billing run includes items with different terms, Carillon separates those items into different invoices at invoicing time, so each invoice carries the correct terms and format.

NetSuite's documented native workflow is different. Oracle's documentation says NetSuite payment terms can be selected on customer records and invoices. When terms are selected on a customer record, those terms become the default on that customer's invoices; Oracle also says terms can be changed on an individual invoice.

For invoice formatting, Oracle documents custom transaction forms and Advanced PDF/HTML templates. Custom forms can be set as preferred or default forms, with preferences controlled by custom-form settings and role settings. Oracle also says that when a custom form uses an Advanced PDF/HTML template, that template defines the print and email formatting and contents for transactions that use that custom form.

The distinction is the level where the billing decision is made. Oracle's documented NetSuite workflow describes payment terms at the customer or invoice level, and invoice formatting through transaction forms and templates. It does not describe the same native item-level override model where the item being sold automatically determines the invoice format and payment terms, including separating items into different invoices when different terms apply. Carillon provides that item-driven control as part of the standard billing setup.

Sources: Oracle NetSuite Documentation: Creating Terms of Payment (payment terms defined per customer or vendor; applied to invoices by choosing a term on the invoice record or by setting default terms on the customer record); Oracle NetSuite Documentation: Custom Transaction Forms Properties (custom forms, preferred form settings, Advanced PDF/HTML template assignment); Oracle NetSuite Documentation: Advanced PDF/HTML Templates (template defines print and email formatting for transactions using that custom form).

Efficient order entry depends on more than entering items and quantities. Many customers have specific ordering requirements, and those requirements need to be applied consistently without relying on users to remember special handling instructions.

Carillon allows key order-entry rules to be defined directly at the customer level. For each customer, Carillon can specify:

• Whether the customer accepts partial orders.
• Whether the customer should receive order acknowledgments.
• The order acknowledgment format for that customer.
• The customer's minimum order amount.
• Whether a purchase order is required.

Because this logic is built into Carillon, these rules are applied during normal order processing. A customer that requires a purchase order can be handled differently from one that does not. A customer that does not accept partial orders can be handled according to that rule. A customer with a minimum order amount can be checked during order entry. A customer that requires an order acknowledgment can receive one in the correct format.

This is also an example of how Carillon evolves. When customers request enhancements that solve real operational problems, Carillon can build those enhancements into the core system. Once added, the functionality becomes part of the standard product rather than remaining a one-off customization for a single customer.

NetSuite documents several related capabilities, but they are not presented as the same single customer-level order-entry control set. Oracle documents preferred transaction delivery on customer records, where each customer can have default delivery preferences for transactions by email, print, fax, or a combination of those methods. Oracle's list of automatically generated transaction emails includes sales orders. Oracle also documents sales-order entry, including a PO Number field on the sales-order header.

For fulfillment and billing, Oracle documents NetSuite order-fulfillment workflows, including Advanced Shipping, which allows fulfillment and billing to occur as separate transactions. For minimum order amounts, Oracle documents minimum order enforcement for web store checkout, where customers can be restricted from checking out until they reach a minimum total sales amount.

The distinction is where the order-entry rules are defined and enforced. Oracle's documented NetSuite workflow describes transaction delivery preferences, sales-order header fields, fulfillment and billing workflows, and web store minimum order settings. It does not describe the same native customer-level order-entry control set for partial-order acceptance, order acknowledgment requirement, acknowledgment format, minimum order amount, and purchase-order requirement. Carillon provides those controls as part of the standard order-entry setup.

Sources: Oracle NetSuite Documentation: Preferred Transaction Delivery on Customer and Vendor Records (per-customer defaults for email, print, and fax delivery of transactions including sales orders); Oracle NetSuite Documentation: Creating an Invoice (PO Number field on sales-order header; terms applied at customer or invoice level); Oracle NetSuite Documentation: Minimum Web Store Order Amount (minimum order enforcement documented for web store checkout, not native order entry).

Carillon publishes its SaaS license pricing, currently $5,000 USD per month, and details exactly what is included.

The license is for unlimited internal and external users, including external shopping cart users, so customers do not have to buy additional Carillon user licenses as more authorized users interact with the system.

The SaaS license includes the full Carillon ERP ecosystem, with no supplemental software licenses for additional modules, interfaces, or features offered by Carillon. Because the full ecosystem is included, customers can grow into the system without later having to purchase additional Carillon modules or features as their needs expand. The following are included at no additional charge:

• Carillon ERP
• Carillon Everywhere®
• Carillon Document Imaging
• Carillon's Mail feature
• Carillon's payment-processing interface(s)
• Carillon's Avalara interface (the customer still needs the applicable Avalara account or subscription)

The subscription also includes Microsoft Teams support (phone, chat, and screen-sharing) for one designated support contact, one named-user Carillon ERP University subscription, and new versions of Carillon ERP as they are released. Separately priced items are services, not add-on software modules. Those services include implementation, training, custom development, data conversion, and report writing, and may be provided by Pettit Consulting, P.C., the developer of Carillon ERP and provider of services on behalf of Carillon, under a premium support agreement, fixed-fee arrangement, or hourly services agreement. Customers are not required to purchase optional services beyond those included in the SaaS license agreement.

Carillon's monthly price is fixed under the agreement except for an annual CPI-based inflation adjustment. Prospects should review Carillon's SaaS license agreement for complete terms and conditions. The SaaS license agreement supersedes any statements made in this reason.

NetSuite's public pricing materials describe a different model. NetSuite states that its annual license is made up of three main components: the core platform, optional modules, and the number of users, plus a one-time implementation fee. Oracle's NetSuite documentation states that each user who needs to interact with NetSuite must be assigned an appropriate license, and it identifies different license types for different roles and usage patterns.

NetSuite's Modules Guide lists dozens of named modules and module-family products across areas such as financial management, CRM, business intelligence, inventory and order management, connectors, commerce, human resources, field service management, professional services automation, and supply chain. NetSuite states that modules can be licensed separately, module licensing fees vary, all modules are optional, and modules must be licensed to enable their functionality.

As a result, a NetSuite prospect generally has to evaluate the core platform, expected user licenses, and which optional modules or module-family products are required before estimating total software licensing cost. For buyers who want a clear starting point before requesting a vendor quote, Carillon is easier to evaluate up front: one published SaaS license price, unlimited internal and external users, the full Carillon ERP ecosystem included, no supplemental Carillon module or feature licenses to evaluate later, and separately priced services identified separately from software licensing.

Sources: Oracle NetSuite, NetSuite Modules Guide (lists optional modules and states modules must be licensed to enable their functionality); Oracle NetSuite, How Much Does NetSuite Cost? (describes three-component annual license structure: core platform, optional modules, and number of users); Carillon ERP, SaaS License Agreement (governs pricing, inclusions, and terms; supersedes any statements made on this page).

Carillon supports Schedule R (Form 941) for aggregate Form 941 filers. This is valuable for organizations that operate payroll across many related legal entities and have IRS approval to file aggregate employment tax returns.

For example, a franchisee group with dozens of stores, where each store is its own legal entity, may otherwise need to file separate quarterly Forms 941 for each employer. After the required IRS approval, the filer can file one aggregate Form 941 with Schedule R allocating the wage, tax, deposit, and payment information by client or employer.

The IRS describes Schedule R as the allocation schedule for aggregate Form 941 filers, and states that a section 3504 agent files one aggregate return for each period on behalf of all employers it represents using the agent's own EIN and address.

Carillon also supports the related consolidated W-2 reporting workflow for this structure.

We were unable to find public Oracle documentation specifically identifying support for Schedule R (Form 941).

For organizations that need aggregate Form 941 reporting, Carillon's Schedule R support can reduce payroll tax filing complexity: one aggregate Form 941 with Schedule R allocation detail instead of separate Form 941 filing workflows for each approved employer, plus support for the related W-2 reporting workflow under the section 3504 agent structure.

Picture a customer walking into a bike shop and ordering ten bikes with horns installed on the handlebars.

In Carillon, the salesperson can handle the request directly from the Sales Order Entry window. The horn can be added to the bike's first-level bill of materials for that order. An operation can also be added to install the horns in the repair shop. In Carillon, an operation is a task performed in a work center, and an operation can have a price associated with it.

The sales price can include both the added horn and the installation charge. If the bikes are not in stock, Carillon can create the production order to build ten bikes with horns. If the bikes are already in stock, Carillon does not need to create a production order to build the bikes, but it can still create a work order to install the horns on the bikes.

The point is flexibility: Carillon lets the user handle the material change, the added labor operation, the related pricing, and the needed production/work order directly from the Sales Order Entry window.

NetSuite appears able to accomplish much of the same business result through NetSuite CPQ Configurator and NetSuite CPQ Manufacturing. Oracle documents that CPQ Manufacturing uses materials and routing steps from configured items added to the sales order by CPQ Configurator. Oracle's documented workflow says that, after the configuration is submitted and the sales order is saved, the user can edit the sales order and click Convert WO to create the work order.

Carillon has not reviewed CPQ Configurator or CPQ Manufacturing directly. Based on Oracle's available documentation, NetSuite appears able to accomplish much of the same business result, but through CPQ configuration functionality and a later Convert WO step, rather than by simply handling the material change, installation operation, pricing, and production/work order creation directly in the Sales Order Entry window.