Compliance software rarely operates in isolation. It has to work alongside your existing purchasing system, your document storage, and whatever EHS processes your team already runs. Before evaluating features in isolation, it's worth asking how a platform actually fits into what you're already using.
Where integration friction usually shows up
- SDS files scattered across email, shared drives, and supplier portals with no single import path
- Purchasing or ERP systems that already track chemical quantities, duplicated instead of connected
- Facility and contact data re-entered manually because it doesn't sync from an existing system
- Reports that have to be manually reformatted before a state portal will accept them
Common integration types: manual, file import and API
Inventory and SDS data usually reaches a compliance platform in one of a few ways. Which one fits depends on how often your source data changes and who maintains it, not on which sounds most advanced.
- Manual entry: workable for a short, stable list; every change depends on someone remembering to update it
- Spreadsheet or CSV import: the most common migration path; easy to review before loading, but only as current as the last export
- Scheduled file transfer: a regular export from an ERP or purchasing system; needs a fixed format and a person who checks the rejected rows
- API connection: systems exchange records directly; can keep data current, but needs IT ownership, credentials management and error monitoring
- Bulk document upload: loading existing SDS PDFs into a library, where fields can then be extracted and reviewed
Ask each vendor which of these it actually supports today, for which data types, and whether any of them is a paid project. A roadmap item is not an integration.
Field mapping: what an inventory import needs
Whatever the method, the work is the same: every source field has to land in the right target field, in the right unit, with a rule for what happens when it doesn't. In chemical inventory software, the fields that matter most for Tier II are the facility, the storage location, the chemical identifier, the SDS it ties to, and the quantity with its unit, because threshold checks use the maximum amount at any one time, per facility.
Units cause the most quiet errors. Purchasing systems often count containers (drums, totes, cases), while Tier II thresholds are in pounds. Converting a liquid from gallons to pounds needs a density or specific gravity, usually from the SDS, and a container count needs a known fill size. Record the conversion basis next to the converted number so a reviewer can check it.
| Source field | Target field | Format / unit | Transformation | Validation rule | Error handling |
|---|---|---|---|---|---|
| Plant code (PLT-02) | Facility | Text code | Look up the code in a facility mapping table | Code must match an existing facility | Reject row; list unmatched codes |
| Bin location (B2-R14) | Building / room | Text | Split into building and room | Location must exist under that facility | Hold row for review; suggest nearest match |
| Item description + CAS | Chemical identifier | CAS as digits-digits-digit | Trim spaces; normalize the CAS format | CAS check digit valid; name matches the SDS | Flag missing or invalid CAS; never guess |
| Supplier SDS ID + revision date | SDS reference | Text + date | Link to the SDS library record | Linked SDS exists and is the current version | Flag rows with no linked SDS |
| On-hand quantity | Quantity | Number | Convert using the unit row below | Numeric and not negative | Reject non-numeric values; report zeros separately |
| Unit of measure (GAL, DR, KG) | Unit | lb for threshold checks | GAL × density; DR × fill size; KG × 2.20462 | Unit is on the approved list with a known basis | Reject unknown units; show conversion basis |
Example only. Field names, codes and rules are fictional; agree the real mapping with your vendor and your source-system owner before the first import.
Questions worth asking before you commit
- Can I bulk-upload existing SDS files, or does everything need to be re-added one at a time?
- Does the platform accept data from spreadsheets or a supplier feed, or only manual entry?
- Does report output import directly into state and federal systems, or require reformatting?
- If I already track inventory elsewhere, does that duplicate effort or reduce it?
- Which import methods are available today (manual, spreadsheet, scheduled file or API), and for which data?
- When a row fails validation, what do I see, and can I fix and re-import just that row?
- Does a repeat import update existing records or create duplicates?
A test-import checklist before go-live
Before you trust an import for reporting, run a deliberately messy test file through it: a copy of your real export with a few planted problems. The goal is to see how the system fails, not just that it succeeds.
Test-import checklist
- Duplicate records: include the same product twice with slightly different names; confirm it's flagged, not double-counted
- Missing identifiers: leave the CAS blank on one row; confirm the row is held for review rather than loaded as an unknown chemical
- Invalid units: use a unit the system doesn't know (for example, "BKT"); confirm the row is rejected with a clear message
- Missing conversion basis: send a quantity in gallons for a product with no density on file; confirm it isn't silently treated as pounds
- Rejected rows: confirm you get a downloadable list of every rejected row and the reason
- Unmatched facility or location: use a code that doesn't exist; confirm nothing loads into the wrong site
- Repeat import: load the same file twice; confirm quantities update rather than double
- Partial failure: confirm whether good rows load when others fail, and that you can tell which is which
- Audit trail: confirm each imported change records the source file, date and person who ran it
- Reconciliation: compare imported totals per facility against the source system before relying on them
From imported data to the Tier II report
Clean inventory data is only useful if it flows into threshold checks and the report without being re-keyed. Ask to see the handoff: an imported quantity change should update the threshold result for that facility and appear in the draft report. In NeoTech's Tier II reporting software, inventory totals roll into Tier II, thresholds are calculated per chemical per site, and the output is a .t2s file for Tier2 Submit or E-Plan import where accepted, plus a PDF for the binder. Ask NeoTech which import methods are available for your specific source systems, and confirm the format your state accepts.
Why this matters more than it seems during a demo
A platform can look complete in a sales demo built around a single sample facility, and still create real friction once your actual SDS backlog, multiple facilities, and existing processes are involved. The real test is migration: how much manual work does it take to get your current data into the new system, and does it stay current afterward without repeated manual re-entry.
Official source
The federal requirements described in this article are established under the Emergency Planning and Community Right-to-Know Act (EPCRA). Always verify current state-specific rules with your SERC.
SourceEPA Tier II Forms and InstructionsRegulatory statements in this article were checked against the official sources linked above on .