Software companies
ERP partners and VARs: who owns customizations and scripts built for clients?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Who owns ERP customizations a partner builds is decided first by the contract. If the statement of work assigns deliverables, bespoke scripts and workflows go to the client; if it is silent, code written by the partner's employees generally stays with the partner and the client relies on a license. Partner products and platform vendor code keep their own owners.
Key takeaways
- The services agreement and statement of work decide ownership before any default rule applies.
- Custom code from an independent partner usually falls outside the commissioned work-made-for-hire categories, so ownership moves only by written assignment.
- Reusable libraries and SuiteApps stay with the partner when the contract carves out pre-existing tools.
- Client transaction and master data is the client's customer data under the platform's terms.
- Scripts often embed client names and internal IDs, which must be removed before any reuse or licensing.
The short answer: the contract governs#
The contract governs who owns ERP customizations, and most ownership disputes trace back to a statement of work that never said. Well-drafted master services agreements and statements of work for NetSuite, Acumatica, Dynamics or Sage implementations address ownership of deliverables, pre-existing materials and any license back to the partner.
Read three clauses together: the assignment of deliverables, the pre-existing or background IP carve-out and any license that flows back to the partner. Together they say who owns a client-specific script, who owns the library it calls and whether the partner may reuse what it learned on the project.
What US copyright law does when the contract is silent#
When the contract is silent, US copyright law starts from authorship. The Copyright Office's Circular 30 explains that a work made for hire arises when an employee creates the work as part of regular duties, or when a work in certain statutory categories is specially commissioned under an express written agreement.
Under 17 U.S.C. 201(b), the employer or commissioning party in a work made for hire is treated as the author and owns the copyright unless a signed writing says otherwise. The commissioned categories in 17 U.S.C. 101 include contributions to collective works, compilations, instructional texts and a few others; custom ERP code written by an outside partner often fits none of them, so ownership moves to the client only by written assignment.
In practice, a partner's employees usually create code the partner owns, and a client that wants ownership needs an assignment. The client's right to run and modify code it does not own then rests on whatever license the contract grants or implies, which is a question for counsel.
Bespoke work vs partner product vs platform reservations#
Bespoke work, partner products and platform vendor code each follow a different ownership pattern. The table shows the usual position under a typical partner contract; your own paper may move any row.
On the last row, platform terms are usually explicit. Oracle's NetSuite Terms of Service define Customer Data as content the customer provides that is stored in, or run on or through, the Cloud Service.
| Category | Examples | Usual owner | What to check |
|---|---|---|---|
| Bespoke client work | SuiteScripts for a client's approval flow, custom records, saved searches, workflows, custom reports | The client if the SOW assigns deliverables; otherwise the partner, with a license to the client | Assignment wording and when ownership transfers, such as on payment |
| Partner products and accelerators | SuiteApps, reusable script libraries, connectors, templates, bundles | The partner, when pre-existing and general tools are carved out | Whether the carve-out exists and covers improvements made during the project |
| Partner know-how and process records | Solution designs, implementation playbooks, ticket histories, internal wikis | The partner, subject to confidentiality of client details | Confidentiality clauses and client names embedded in documents |
| Platform vendor code and APIs | The ERP platform, its scripting APIs, standard objects and modules | The platform vendor | Developer, partner and marketplace agreements |
| Client data and configuration | Customers, items, transactions, chart of accounts, saved data | The client | The platform's customer data definition and the client's own policies |
Clauses that decide ownership#
Clauses that decide ownership tend to sit in the same places in every partner agreement. Check each one in your current templates and in older statements of work still in force, because long-running clients are often on paper nobody has reread.
- Assignment of deliverables: what transfers, to whom and when, for example on full payment.
- Pre-existing and background IP: tools and libraries the partner brought to the project.
- Improvements: whether enhancements to partner tools made during the project transfer or stay.
- License back: the partner's right to reuse generic code, patterns and know-how.
- Residuals: whether general skills and ideas retained in memory are free to use.
- Confidentiality: limits on client business information embedded in code and documents.
- Subcontractors: assignment from freelancers and offshore teams to the partner.
Why ownership matters beyond the client relationship#
Ownership matters beyond the client relationship because it decides what a partner can reuse, sell and license. A partner selling its firm will be asked which code it owns; a partner building a product needs clear title to its libraries; a partner considering licensing its records to AI developers needs to know which scripts are its own.
Code assigned to clients stays out of any partner package. Partner-owned libraries, SuiteApps and the process records around implementations, such as Jira tickets, solution designs and code reviews, can be candidates once client names, internal IDs and business data are removed.
Those process records are often the more interesting part. A ticket thread that traces a failed invoice approval to a misconfigured workflow, with the fix and the client's sign-off, shows ERP problem solving in a way a script alone does not.
Illustrative: a NetSuite partner sorts years of scripts#
Illustrative: a fictional NetSuite partner keeps client scripts in Bitbucket, an internal script library in a separate repository, implementation tickets in Jira and solution designs in Confluence. Its owner wanted to know what the firm actually owned before talking to an acquirer.
The review found that older statements of work assigned all deliverables to clients without carving out pre-existing tools, while newer ones carved out the internal library and granted clients a license to it. Some library functions had been written inside client projects under the older paper.
The partner treated client-specific scripts as client property, kept library functions written under the newer paper as its own and flagged the older functions for counsel review. Tickets and designs, with client names and record IDs removed, were classed as partner process records. The firm also updated its SOW template.
Tightening your statement of work#
Tightening the statement of work prevents the next ownership question. Most fixes are short additions that clients accept when they are explained plainly at the start of a project rather than at the end.
| Clause | Suggested approach |
|---|---|
| Deliverables | Assign client-specific deliverables on full payment, listed by name or category |
| Pre-existing tools | Name the partner library and tools, keep ownership and grant the client a perpetual license to use them |
| Improvements | State that improvements to partner tools remain partner property |
| Reuse | Allow reuse of generic code and know-how that contains no client confidential information |
| Subcontractors | Require written assignment from every subcontractor to the partner before work starts |
How SourceX looks at partner records#
SourceX reviews partner records in the Rights step of the SourceX five-step transaction, separating client-owned deliverables and client data from partner-owned code and process records. Client code never moves into a partner package.
For whatever proceeds, the SourceX Evidence Packet writes down the basis for including each record family: provenance, licensing rights, permitted use, the privacy record and release authorization.
Frequently asked questions
Does a client who paid for a customization automatically own it?
No. Payment alone does not transfer copyright. Ownership moves to the client when the contract assigns it in writing, and many agreements make that assignment conditional on full payment. Without an assignment, the client usually has a license to use what it paid for, defined by the contract.
Can we reuse code we wrote for one client with another?
That depends on whether the code was assigned and on confidentiality terms. Generic patterns and partner-owned library code can usually be reused. Client-specific scripts that were assigned, or that embed the client's business logic, should not be. Clear carve-outs in the SOW make the line easier to draw.
Who owns a SuiteApp we built and sell on the marketplace?
Usually the partner, as long as it was developed outside client deliverables or under a carve-out. The platform's developer and marketplace agreements also apply and may set conditions on distribution. If parts were built during a client project, check that project's SOW.
What about code our freelancers or offshore contractors wrote?
An independent contractor generally owns what it writes unless a signed agreement assigns it, because most custom code falls outside the commissioned work-made-for-hire categories. Make sure each subcontractor agreement assigns work product to your firm, or you may not be able to pass ownership to clients.
Does the platform vendor claim rights in partner scripts?
Platform vendors own their platform and APIs, and their developer agreements govern how partners use them. Whether a vendor claims anything in partner-written code depends on those agreements, so read the current versions for each platform you build on rather than assuming.
Sources
- Copyright Office Circular 30 explains a work made for hire arises either when an employee creates the work as part of regular duties, or when a work in certain statutory categories is created under an express written agreement with a party specially ordering or commissioning it. Source
- 17 U.S.C. 101 defines a work made for hire as a work prepared by an employee within the scope of employment, or a specially ordered or commissioned work in listed categories, such as a contribution to a collective work, a compilation or an instructional text, if the parties expressly agree in a signed written instrument. Source
- 17 U.S.C. 201(b) provides that in the case of a work made for hire, the employer or other person for whom the work was prepared is considered the author and, unless the parties have expressly agreed otherwise in a written instrument signed by them, owns all of the rights comprised in the copyright. Source
- Oracle's NetSuite Terms of Service define 'Customer Data' as content the customer provides that is stored in, or run on or through, the Cloud Service. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.