How to use an inventory management requirements checklist before choosing a platform
A team that must choose and run a self-hosted inventory system, whether Odoo, ERPNext or OpenBoxes, should first turn its operational needs into testable requirements. Each requirement should describe a behavior the warehouse, finance or compliance team must see in the system, and each should carry a verification method such as a scripted test with sample stock, a timed barcode count or a demo using the organization's own data. Write the requirements before any platform demo, so vendor presentations are scored against your list rather than shaping it. Group the list into five areas: functional (locations, lot, serial and expiry tracking, valuation, replenishment, reporting), security (access roles, audit logs, encryption), integration (purchasing, ecommerce, accounting, scanners), operational (hosting, backups, upgrades, training) and compliance (retention and traceability evidence).
Licensing and support decide which requirements a platform can meet at all. Odoo Community is LGPL-3.0 licensed, while features such as barcode scanning apps, Studio customization and upgrade services sit in the Enterprise edition, so a requirement for scanning or upgrade support may change the edition you need. ERPNext is GPL-3.0 licensed and its supported versions have end-of-life dates, so confirm with the vendor or partner which release line you will run and how long it receives support. Ask each candidate to mark every requirement as native, add-on, custom build or not supported, with the edition or version named in writing. Treat any answer that is not in writing as unconfirmed until tested.
Finally, record ownership and acceptance for each requirement before it goes to a bid. Name the business owner who signs off on stock valuation rules, the security owner who signs off on access and logging, and the warehouse lead who signs off on scanning and count procedures. Mark which requirements are must-have for go-live and which can follow in a later phase. This record becomes the basis for a fixed-scope statement of work and for the acceptance tests that show the system works on your sites and your data before cutover.
Which warehouse and stock control requirements to define first
This table lists the stock control requirements to settle before shortlisting Odoo, ERPNext or OpenBoxes, with why each matters for accuracy or audit and how to test it in a demo or test database. Use it as a scoring sheet: a requirement that fails a test on your own sample data should move the platform down the list. Finance and operations should decide the valuation method and tracking granularity together, since both drive reporting and cost.
| Requirement | Why it matters for stock accuracy or audit | How to verify in a demo or test database |
|---|---|---|
| Locations and warehouses | Stock held in the wrong bin or site breaks counts, transfers and site-level reporting | Create two warehouses with internal bins, move stock between them, and check that on-hand quantities update at both ends |
| Lot and batch tracking | Recalls and disputes need to trace a lot to every receipt, transfer and shipment | Receive a lot, split it across two locations, ship part of it, then run a trace report back to the supplier receipt |
| Serial number tracking | Individual units such as devices or equipment need a unique history for warranty and asset audit | Receive serialized items, reject a duplicate serial, and confirm the history shows every move |
| Expiry dates and shelf life | Expired stock must be blocked from issue, and disposal must be recorded | Set an expiry on a test lot, attempt to issue it after the date, and check whether the system warns or blocks |
| Valuation method | Cost of goods sold and inventory value on the balance sheet depend on the costing method chosen (for example, FIFO or moving average, to be confirmed per platform) | Post the same purchase and sale sequence in the test database and compare the valuation report with a manual calculation from finance |
| Scanning and label printing | Scanning reduces keying errors during receiving, picking and counts, and labels must match the lot and serial data | Scan receipt, pick and count on the target handheld or browser, print a label, and confirm the scan updates the correct record |
| Replenishment rules | Reorder points and minimum stock prevent stockouts and unplanned purchasing | Set a minimum on a test item, drop stock below it, and check that the system proposes a purchase or transfer |
| Cycle counts and adjustments | Adjustments without approval are a common audit finding and hide shrinkage | Run a count with a variance, confirm the adjustment requires approval, and check the user and time are logged |
| Reporting and audit trail | Auditors and finance need stock movement history, valuation and user activity on demand | Export a stock ledger for one item over a period and confirm each movement shows the user, date and source document |
How scanning, sites and devices change the requirement list
A single warehouse or a small group of sites on a stable network can treat scanning as a device and browser question first. Staff pick, receive and count from handheld scanners or mobile browsers that talk to one central server, so the main requirements are reliable wireless coverage in every aisle, consistent scanner input into the inventory forms, and printing of labels at the point of use.
- Scanner input: Confirm the scanner emulates keyboard input or works through a vendor app, and that it reads the barcode symbologies your suppliers and labels use.
- Browser and device support: List the handheld models and browser versions staff will use, and confirm each one with the vendor before purchase.
- Label printing: Define label formats, printer models and who maintains print templates, including lot and expiry fields.
- Edition needs: Check whether the barcode or mobile scanning functions you need are included in the edition you plan to run, since some scanning apps are sold separately.
- Network dependency: Record what happens to a receiving or picking session if Wi-Fi drops for a minute.
Ask the vendor to demonstrate a receiving and a count on the actual devices before the requirement is signed off.
When stock sits in several buildings, or at sites with unreliable links, the requirements move from individual devices to how data and updates travel between locations. Each site needs a clear answer on whether it runs its own server or connects to a central one, and on how a stock transfer is recorded when the link is slow or down.
- Hosting model: Decide between one central instance and per-site servers, and write down the outage behavior for each choice.
- Offline capture: Confirm whether scanning and transaction entry can continue during a link loss and how queued records sync afterward.
- Update delivery: Define who applies vendor patches and upgrades to each site, the maintenance window, and how a remote site without IT staff is supported.
- Inter-site transfers: Specify how a transfer is raised, approved and received across sites, and how conflicts from duplicate receipts are resolved.
- Data export: Require consolidated reporting across sites, with stock levels and movement history exportable in a format the central team can reconcile.
Request a written description of the synchronization model and test it with a simulated link loss before go-live.
Depots, plants and field facilities on isolated networks change the requirement list in three places: how software and data move in and out, how devices work without internet access, and how exports meet the transfer rules that apply to the site. Scanning requirements must be tested on the closed network, because some features that depend on outside services may not work there.
- Update delivery by media: Define how vendor packages, security fixes and database changes are verified and carried onto the network, and who signs off each transfer.
- Offline scanning: Confirm that scanners and browsers can run against a local server with no external calls, including fonts, scripts and label services.
- Device management: Plan how handhelds receive configuration and browser updates without internet access.
- Export under transfer rules: Record which data may leave the facility, in what format, and through which approved channel.
- Backup and restore: Specify local backup location, restore testing and retention on the isolated network.
Ask each vendor and integrator to state which features depend on internet access and to confirm device and browser support for a closed network in writing.
Once the environment is clear, the requirement list needs a short set of decisions that the tabs above cannot settle on their own. Write these as acceptance criteria so the implementation partner and the operations team can test them in the same way.
- Environment per site: Mark each location as connected, remote or disconnected, since one organization often runs all three.
- Scanning method: Name the scanner type, input method and label standard for each process: receiving, picking, putaway and counts.
- Offline tolerance: Set the longest acceptable interruption for each process and the recovery step required afterward.
- Update path: Assign an owner, a method and a test environment for every update channel to each site.
- Export and retention: Tie each export to the transfer and retention rules that apply to the records it contains.
Review the completed matrix with the site managers who will run receiving on a busy day, not only with IT.
Security requirements for an inventory system that holds stock and supplier data
An inventory system holds stock levels, supplier terms, purchase history and sometimes customer and payment references, so it falls inside the security scope of many regulated firms. The cards below set out the controls to specify before you choose Odoo, ERPNext or another platform. Where the organization is a covered financial institution, each one maps to a control area in the FTC Safeguards Rule, and the same checks apply to any system that touches financial data.
Encryption in transit and at rest
Require TLS on every browser, handheld scanner and API connection that reaches the inventory system, including connections to supplier portals and the ecommerce site. Then decide how the database, file attachments and backups are encrypted at rest, and who holds the keys. The Safeguards Rule expects customer information to be encrypted in transit over external networks and at rest. Ask the partner to show the certificate setup, where keys live and how backups inherit encryption. Check that encryption still works for the warehouse devices that connect over Wi-Fi.
Multi-factor authentication for every user
Set multi-factor authentication for any individual who can reach the inventory system, including warehouse staff, purchasing users and vendors given portal access. Shared warehouse logins make this control fail, so require named accounts before go-live. Confirm whether the platform supports MFA natively or whether it must come from your identity provider through LDAP or social login. Document the exception process for devices that cannot run an authenticator app, such as fixed-position scanners.
Role-based access by warehouse and site
Define roles that limit what each user can see and change by warehouse, site and function, such as receiving, picking, count approval and valuation. A user at one depot should not view stock or supplier prices at another unless the business needs it. Map roles to your identity groups so leavers lose access automatically. Test the roles with real user scenarios before go-live, including who can adjust stock, write off losses and edit item costs, because those changes move money.
Audit logging of user activity
Record who created, changed or deleted stock, costs, supplier bank details and user permissions, with a timestamp and the old and new values. The Safeguards Rule requires logging of authorized user activity, and the logs must be kept long enough to answer an investigation. Decide where logs are stored, who can read them and whether they are sent to a central security tool. Confirm that the platform logs bulk imports and API writes as well as screen edits, since these are common routes for silent changes.
Change management for configuration and custom code
Treat workflow rules, custom fields, reports and server-side scripts as production changes that need review, testing and a record of approval. In Frappe-based systems, Server Scripts run Python on document events and are disabled by default from version 15, so enabling them is a deliberate decision that should be documented and limited to named administrators. Keep configuration in version control where the platform allows, and require a tested rollback for each change. Ask the partner how they separate test and production databases.
Backup and restore testing
Set a backup schedule for the database, attachments and configuration, and store copies outside the system's own failure domain. A backup that has never been restored is not evidence of recoverability, so schedule restore tests into a separate environment and record the time and result. Include stock counts and valuation reports in the restore check, not only the database. Agree in writing who performs restores, how long a restore is expected to take, and how the team confirms the restored data is complete.
Which compliance evidence an inventory record must support
Before choosing a self-hosted inventory system, decide which compliance evidence your stock records must produce. Inventory data touches several regimes at once: goods receipts, adjustments, write-offs and transfers are business records, and changes to item costs, lot attributes or stock levels are changes to controlled data. Ask your auditor which of these records must be retained, in what form, and who must be able to show that each change was authorized. The answers shape which audit trail, user roles and approval steps the platform must support from day one.
Two federal rules are the most common reference points, but only one may apply to you. If your organization is a broker-dealer, SEC Rule 17a-4(b) requires preservation of certain business records, including bills receivable or payable, for not less than three years, with the first two in an easily accessible place. Whether inventory records fall under that rule, and in what form, is a question for your counsel and records officer, not for the implementation team. If your organization holds customer information in scope of the FTC Safeguards Rule, the relevant duties are logging the activity of authorized users, adopting change management procedures and testing controls. The eCFR text of 16 CFR 314.4 sets out the elements. Inventory is rarely the customer record itself, but a warehouse system that can see customer orders or shipping details may fall within that scope.
DeployOpen prepares systems, controls and evidence for compliance assessments, including configured audit logging, role separation for stock adjustments, change records for configuration and retention settings, and the test evidence described in Safeguards penetration and vulnerability testing. DeployOpen does not issue audit reports, attestations or certifications. Your independent auditor decides whether the evidence is sufficient for your obligations. Confirm with that auditor early which log fields, retention periods and testing frequencies they will accept, and write those requirements into the scope before the platform is selected.
Operational requirements and how to verify each
This table lists the operational requirements that sit beside functional needs in an inventory selection, with the risk when each is missing and the check to run before signing. Use it as a due diligence list for vendors, edition choices and the implementation partner. The main takeaway is that support windows, upgrade paths and restore tests are contract and runbook questions, not technical details to settle after go-live.
| Requirement | Risk if missing | Verification step |
|---|---|---|
| Vendor support window for the chosen version | The version reaches end of support during the stock system's life, leaving no security patches | Ask the vendor for the written support policy and map each candidate version to its end date (for example, Odoo publishes standard support windows per major release, and Frappe publishes supported versions) |
| Edition and support plan match the deployment | Features needed for barcode scanning, multi-company or API access sit behind a tier the buyer did not license | Confirm in writing which edition covers scanning, reporting and external APIs, and whether that edition is permitted for self-hosting |
| Upgrade cadence and upgrade path | Forced or delayed major upgrades break custom stock rules, label templates or integrations | Request the vendor's upgrade calendar, then run a test upgrade on a copy of production data and log every changed workflow |
| Test-before-production practice for upgrades | Stock valuation or lot records shift after an upgrade and nobody notices until a count | Define a test sign-off with warehouse users, covering receipts, transfers, adjustments and valuation reports, before any production change |
| Backup frequency, retention and restore testing | Backups exist but cannot be restored within the time the warehouse can tolerate without stock records | Perform a full restore to a separate host, then check item counts, lot balances and open transfers against a known snapshot |
| Admin ownership and staff training | No internal owner can change locations, units of measure or scanning settings, so every change waits on the partner | Name a primary and backup administrator, document each recurring task, and confirm training completion for warehouse supervisors and counters |
| Stock count and go-live approach | Opening balances are wrong, or the first count reveals discrepancies that stop shipping | Agree a cutover plan with a frozen-stock window, a reconciled opening count per location, and a rollback path that the operations lead has approved |
| Hosting, patching and access responsibilities | Security patches or certificate renewals fall between the partner, the IT team and the vendor | Write a responsibility matrix covering operating system, database, application and devices, and confirm who receives vendor security notices |
What buyers ask before hiring a partner to define inventory requirements
How much effort does defining inventory requirements take before choosing a system?
The effort depends mainly on how many sites, stock locations and product types you run, and on how many systems the stock data has to reach. A single warehouse selling one product line needs a short exercise. Several sites with lot-tracked goods, expiry dates, barcode scanning and an ecommerce feed need a structured review of each process from receiving to shipping, plus a list of every report people rely on today. Expect the work to be iterative: operations staff describe how stock moves, and the requirements are checked against a live sample of items and locations. Ask any partner to show the output they produce, such as a requirements list with a clear owner and priority for each item, before agreeing on scope.
Can our own team write the inventory requirements checklist without a partner?
Yes, many teams can, provided they include the people who handle stock every day. Internal staff know the real exceptions, such as partial pallets, damaged goods and returns, and those details are where requirements go wrong. An outside reviewer adds value by testing whether each requirement can be met by the candidate platforms, and by spotting gaps such as lot tracking that depends on a paid module. Useful inputs to gather internally include a list of locations and warehouses, the current valuation method, the systems that exchange data with inventory, and the reports finance and audit already use. Bring in a partner when the list must be defended to a steering group or when selection depends on edition features you have not yet compared.
What drives the cost of a requirements workshop for inventory?
The cost is driven by the time that partner staff and your staff spend, so the main factors are scope and the number of people in the room. More sites, more integrations and more product categories mean more sessions and more data to inspect. Regulated stock, such as items with lot or expiry rules or traceability obligations, adds review time for compliance and quality staff. Ask for a quote that lists the workshops, the people expected to attend, the sample data reviewed, and the written deliverable. Confirm whether the quote includes a review of edition needs and a comparison against the platforms in scope. DeployOpen does not publish a price list, and a quote follows from the written scope.
How long does requirements definition take before a platform is selected?
The timeline depends on how many decision-makers must sign off and how quickly operations can answer questions. A small, single-site scope can often be defined in a short period, while a multi-site, multi-company rollout needs several rounds of review with warehouse, finance and IT. Delays usually come from unresolved questions about valuation, edition features and integrations, not from the writing itself. Ask the partner to agree the review milestones and the decisions each one must close in writing. Confirm with your own steering group how long sign-off takes, because that is often the real constraint.
What does the requirements work need from operations and finance staff?
Operations staff need to explain how stock is received, put away, picked, counted and adjusted, and to supply real examples of exceptions. Finance staff need to define the valuation method, the posting rules for stock movements, the period-end close steps and the reports auditors expect. Both groups should confirm which data must be migrated and what cleanup is needed first. Plan for a named business owner for each area who can make decisions, because open questions left with those owners slow the schedule. Clarify with finance whether stock values must reconcile with the general ledger each period, since that changes how the accounting link is specified.
Which edition and licensing questions should we settle first?
Settle the features you cannot work without before comparing products. For Odoo, the Community edition is licensed under LGPL-3.0, while the Enterprise source is not publicly available and requires a subscription or partner access. Barcode scanning, mobile apps, multi-company and external API access depend on the edition and plan, so confirm each one against the current pricing page before deciding. For ERPNext, the software is GPL-3.0 licensed and free to self-host, but Frappe support warranty depends on a matching support plan and a supported version. Check the Frappe supported versions page, because version 14 reached end of life on January 31, 2026. Write down which features are needed on day one and which are optional later.
What should the requirements checklist cover for compliance and audit?
The checklist should record which data must be retained, who can change stock records, and how changes are logged. Inventory data often feeds financial statements, so ask whether valuation records must be kept in line with the accounting rules that apply to your organization. Regulated sectors may add duties, such as encryption and multi-factor authentication under the FTC Safeguards Rule for covered financial institutions, or record retention under SEC Rule 17a-4 for broker-dealers that hold such records. DeployOpen prepares systems and evidence for assessments, but independent auditors issue any audit report or certification. Confirm with your compliance lead which obligations apply before writing requirements.
Which questions separate inventory platforms during evaluation
This sequence turns vendor claims into checked answers, so the shortlist reflects what the platform does on your items, your devices and your support terms. Each step ends with a written result you can compare across candidates.
Confirm edition features in writing
Ask each vendor, in writing, which edition includes barcode scanning, multi-company operation and external API access, and which of those features require a paid subscription or a specific plan. For Odoo, the pricing page places multi-company, external API access and custom modules only in the Custom plan, and the barcode app is Enterprise-only, so confirm the exact plan that matches your requirement. For ERPNext, confirm which scanning and API features your chosen hosting option supports. Done means a signed-off feature matrix that names the edition, plan or hosting option for each requirement.
Test lot and expiry tracking with real item data
Load a representative sample of your items, lots, expiry dates and locations into a trial or test instance, and run receiving, transfer, reservation and adjustment transactions against them. Check that expiry dates drive picking order, that lot numbers survive transfers and returns, and that reports show remaining quantity by lot and location. Ask the vendor or partner to demonstrate these steps live, not from slides. Done means a recorded test script with pass or fail results for each case, reviewed by the operations owner.
Test scanning on the devices you will use
Run picking, receiving and cycle count scenarios on the handheld devices, browsers and label printers that the warehouse will actually use, including a location with weak Wi-Fi coverage. Confirm how the system behaves when the network drops during a transaction and whether the scanned data is queued or lost. Record which scanner models, browser versions and label formats worked. Done means a device compatibility list and a note on offline behavior that the operations team has accepted.
Check support windows and upgrade obligations
Request the vendor's published support window for each candidate version, the date each major version leaves standard support, and the upgrade obligations for your hosting model. For Odoo, the documentation describes three years of standard support after a major release, with security patches limited to that window, and mandatory major upgrades every two years on Odoo Online and Odoo.sh. For ERPNext, Frappe's supported versions page lists end-of-life dates, and warranty coverage depends on being on a listed version with a matching support plan. Ask who performs and pays for each upgrade and how long a test upgrade takes. Done means a written support and upgrade schedule that your compliance and IT leads have reviewed.
Request a restore test on a copy of production-like data
Ask the partner to back up a test database, restore it to a separate environment, and confirm that stock quantities, lots, locations and attachments match the source. Include a partial restore and a restore after a simulated failed upgrade. Ask how long the restore took and who runs it on your side. Done means a restore log with record counts reconciled against the source and a documented runbook for your team.
Confirm every answer with the vendor before shortlisting
Send the collected answers, test results and device list to each vendor and ask them to confirm or correct each point in writing. Flag any answer that depends on a feature not included in the quoted edition or on a third-party add-on that you have not tested. Treat undocumented or verbal answers as open items until they are confirmed. Done means a shortlist decision record that lists each confirmed answer, its source and the person who confirmed it.
How DeployOpen scopes and delivers inventory requirements and selection work
DeployOpen works with your operations, finance and IT teams to turn warehouse and stock rules into a written requirements list before any platform is chosen. We then test the shortlisted open-source options against those rules in your own infrastructure, so the selection rests on your traceability, scanning and integration needs.
How we scope
- Each engagement starts with a written scope covering sites, locations, lot, serial and expiry rules, and valuation method.
- We document which purchasing, ecommerce and accounting integrations are in scope, and which data each one must carry.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
How we build
- We build a test environment in your cloud account, data center or air-gapped network to trial Odoo, ERPNext or OpenBoxes against your sample stock records.
- We check barcode scanning, label printing and replenishment rules against real warehouse workflows before any platform is recommended.
- We test integration paths with purchasing, ecommerce and accounting systems and record where edition features or custom code are needed.
How we hand over
- You receive the signed requirements checklist, the option comparison and the reasoning behind the platform recommendation.
- Configuration, integration and hardening decisions are documented so your own staff can maintain and audit the inventory setup.
- We plan data import and stock count procedures with your team, including the test runs needed before a warehouse go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the selection work is complete.
- Retainers can cover platform version upgrades, backups and changes to lot, expiry or valuation rules as operations evolve.
- Security testing of the chosen inventory platform and its integrations can be scheduled alongside regular maintenance.
