

How Repligen Built an AI-Driven Central Trade Compliance System Across Seven Acquired ERPs
Engagement at a glance
Investment
~$1.2M
one-time, 7-ERP rollout + data standard
Timeline
~1 year
9-mo build + 3-mo rollout
Delivery
5 milestones
fixed scope, paid on acceptance
Payback
~1 year
annualized savings ≈ investment
Outcomes in production
ERP systems unified
7 → 1
single classification layer on top
Quarterly compliance reporting
82%
fewer hours per cycle
Annual USITC HTS audit
9 wk → 11 d
across 16K+ SKUs
Annualized savings
~$1.2M
labor and risk reduction
Inside the partnership between GingerControl and Repligen, the global bioprocessing manufacturer, where GingerControl became the AI-driven central trade compliance system sitting across seven inherited ERPs, sixteen thousand SKUs, and an acquisition cadence that does not slow down.
Seven Inherited ERPs. Sixteen Thousand SKUs. One AI-Driven Central Trade Compliance System Running Across All of Them.
Company Background and the Problem
Acquisitions kept arriving, the trade-compliance stack did not
Repligen is a global bioprocessing manufacturer serving biopharma and CDMO customers across more than thirty countries. Its growth strategy is unusual for the sector, one to two manufacturer acquisitions a year, layered on top of an already deep catalog of bioreactors, filtration systems, chromatography media, and analytics instruments. By the time Repligen approached GingerControl, the actively imported catalog had grown past sixteen thousand SKUs.
Every acquired company arrived with its own ERP. Some had been built in-house years ago, others were standard packages configured by a long-departed integrator. Seven distinct ERPs were live in production, each holding part of the truth about what Repligen actually sold, where it was made, and how it was classified for customs. Pulling a single trade-compliance report meant pulling from seven systems, normalizing seven schemas, and reconciling fields that disagreed about basic facts.
Repligen’s brief to us was unusually direct. They did not want another reporting tool bolted onto the side. They wanted an AI-driven central trade compliance system that could read across every ERP, produce a single global view of classification, reporting, and audit, and absorb every future acquisition without rebuilding the system each time. The hardest part of the build, by a wide margin, was the data standardization that had to come first.
Pain Points and Solutions
Three structural problems, three paired interventions
The engagement opened with a four-week assessment. The trade team walked us through a quarter of past reports and we walked them through where their hours were going. Three patterns emerged.
Pain 01
Cross-ERP reporting was a manual reconciliation job
Assembling a single quarterly trade-compliance report meant pulling extracts from seven ERPs, mapping each one into a working spreadsheet, and chasing differences across columns that should have agreed. The trade team was spending 80+ hours per cycle on assembly before any analysis began.
Solution
We built a unified data layer that reads from every ERP through a thin connector and writes into one canonical compliance schema. Each new acquisition gets a connector built once, and the canonical schema absorbs it without disturbing the layers above. Quarterly reports now generate from a single source.
Where the trade team’s quarterly hours went
Hours spent per quarter to assemble and analyze one cross-ERP trade compliance report, before the engagement and twelve months after deployment. Bar width is proportional to total hours.
Hours reclaimed per cycle
0h
Pain 02
The annual USITC HTS update swallowed two months
When USITC publishes its annual HTS revisions, sixteen thousand SKUs need to be re-evaluated. A revision is rarely a clean delete, it is often a split, a merge, or a newly added subheading that fits a product better than the code currently in use. Before the engagement, the trade team handled this by manually re-checking every SKU against every change, a project that consumed roughly nine weeks each year.
Solution
We built a global classification service that watches USITC publications, diffs each change against Repligen’s current SKU-to-HTS map, and surfaces only the SKUs whose current code is plausibly stale. The trade team now reviews a ranked exception list instead of the full catalog. Annual audit time dropped from nine weeks to eleven days.
Annual USITC HTS audit, before and after the AI brain
Time the trade team needed to complete a full audit of 16,000+ SKUs against the year’s USITC HTS revisions. Same scope, same standing team.
Audit time reclaimed
0d
Pain 03
No shared standard for compliance data made audits painful
Because each acquired ERP stored compliance data in its own conventions, country-of-origin in one schema was a free-text field, in another a coded reference, in a third a derived value. There was no shared definition of what a compliant record looked like, which meant every audit started with weeks of data cleaning before the audit itself could begin.
Solution
We worked with Repligen’s trade team to design a single Trade Compliance Data Standard, the canonical schema, the required fields, the validation rules, and the ownership for each field. The standard is now encoded into the unified data layer, so non-compliant records are surfaced at write time instead of audit time. The same standard governs how every new acquisition’s ERP is onboarded, and the AI brain reads from it without having to learn the quirks of each underlying system.
Standardization inventory
What had to be unified before the AI brain could read across ERPs
The scope was agreed in the first month and frozen before any build began. Six data domains, one canonical definition each, every field with a named owner.
01
Product master
SKU naming, product description structure, unit of measure, bill of materials, net and gross weight, dimensions.
02
Classification
US HTS, ECCN, Schedule B, foreign HTS for major destinations, prior CBP rulings referenced for each SKU.
03
Country of origin
ISO country code, manufacturing site, substantial transformation evidence, FTA eligibility flags per program.
04
Party master
Supplier, manufacturer, and customer records consolidated under one canonical ID, with EORI, MID, and TIN attached.
05
Valuation
Transaction value, assists, royalties and license fees, selling commissions, freight and insurance allocation rules.
06
Programs and documents
Section 232, 301, 122 applicability, ADD/CVD scope, GSP and preference indicators, plus naming and retention rules for CI, PL, BOL, and COO.
Budget, Timeline, and Delivery
How we scoped, priced, and shipped it
We price engagements the way we run them: scope first, fixed against a defined deliverable, no open hourly meter. A central trade-compliance system across seven ERPs is a large build, so the scope was frozen up front and the budget tracked it. Here is how the Repligen engagement was budgeted, sequenced, and delivered.
The Budget
Fixed scope, paid against delivered milestones
We scoped the engagement to a fixed deliverable, a central trade-compliance system reading across all seven ERPs into one canonical standard, with the global classification service on top, and priced it as a fixed fee paid against milestones, not an hourly meter. Repligen knew the number before the build began, and each payment tracked a milestone they could accept.
Pricing model
Fixed scope, milestone-based
paid per accepted milestone, not hourly
Engagement investment
~$1.2M
one-time, 7-ERP rollout + data standard
Payback
~1 year
annualized savings ≈ the build cost
The investment paid for itself fast. The system removed roughly $1.2M a year in labor and risk, so the one-time build returned its cost inside the first year and keeps returning it every year after. Each new acquisition now onboards through the same layer in about six weeks instead of six months, so the cost of growth dropped too.
The MVP
The smallest thing that produced one global report
We did not boil the ocean. The MVP was the smallest deliverable that could produce a single, trustworthy cross-ERP compliance report from the canonical layer. Everything else was named and deferred, so scope could not creep across seven systems.
In the MVP
- Canonical data standard, frozen, with field owners
- Connectors live for the first ERPs into the unified layer
- One quarterly compliance report generated from the layer
- Global classification service watching USITC changes
Deferred to phase two
- The remaining ERP connectors, rolled out after
- Self-serve dashboards and ad-hoc analytics
- Destinations and programs beyond the first scope
The Timeline
Nine months to build, three to roll out
The year split into nine months of build and three of rollout. Development ran through the first four milestones, the data standard first because it was the hardest, then the unified layer, the first live report, and the classification service across all seven ERPs. The final three months were testing, training the trade team, and evaluating the system against the baseline before sign-off.
- 1
Month 1–3
Assessment and data standard
Walked a quarter of past reports, mapped where the hours went, and designed the canonical Trade Compliance Data Standard, six domains with an owner on every field.
Deliverable: Signed data standard and fixed scope, fixed price confirmed.
- 2
Month 4–5
Unified layer and first connectors
Stood up the canonical layer and built connectors from the first ERPs, each writing into one schema.
Deliverable: First ERPs flowing into the unified layer.
- 3
Month 6–7
One report, end to end (MVP)
Generated a full quarterly compliance report from the layer instead of seven spreadsheets stitched by hand.
Deliverable: Quarterly report produced from a single source.
- 4
Month 8–9
Classification service and remaining ERPs
Connected the USITC-watching classification service, then rolled the remaining ERPs onto the unified layer so all seven were live.
Deliverable: All seven ERPs unified, classification service live.
- 5
Month 10–12
Testing, training, and evaluation
Ran end-to-end testing across all seven ERPs, trained the trade team on the new reporting flow, and evaluated the system against the baseline before sign-off.
Deliverable: Team trained, results validated against baseline, signed off.
Delivery and Acceptance
Nothing was signed off until a real report came out clean
Every milestone had an acceptance test Repligen owned. The data standard had to be signed by the field owners. The MVP had to produce a quarterly report that matched a hand-built one. The classification service had to surface the right stale SKUs against a known USITC change. Payment followed acceptance, not the calendar.
The rollout was staged, not a big-bang. ERPs moved onto the layer in tranches, and the trade team kept its old process running until each tranche passed its acceptance test. A failed stage was fixable before the next ERP came on, which is the whole point of sequencing a seven-system migration this way.
The Results
What the first full year looked like
In the twelve months after deployment, Repligen’s trade team stopped spending its quarters assembling reports and started spending them reviewing the contents. The annual HTS audit, previously treated as a multi-month project that required borrowed analyst capacity, finished inside two weeks with the standing team. Repligen has since absorbed two additional acquisitions through the new onboarding pattern, each connected to the unified layer in roughly six weeks, against the six months the pre-engagement process typically required.
| Metric | Before | After | Change |
|---|---|---|---|
| Quarterly compliance reporting | 80+ hours per cycle | 14 hours per cycle | 82% reduction |
| Annual USITC HTS audit | ~9 weeks | 11 days | 83% reduction |
| New acquisition ERP onboarding | ~6 months | ~6 weeks | 75% reduction |
| SKUs under continuous classification monitoring | Sampled, manual | 16,000+, automated | Full coverage |
| Annualized labor and risk savings | Baseline | ~$1.2M | Captured year one |
What Repligen valued most was the operational shift. The trade team no longer functions as a reconciliation desk that happens to also handle classifications. The reconciliation tax was paid once at the data layer, so the team’s hours could go into the judgement work that classifications actually require.
What happens next
If your trade team is reconciling more than it is classifying, that is the conversation to start with.
We begin every engagement with an assessment of where the hours are actually going. The output is a written diagnosis of the friction in your trade-compliance stack, whether or not we go on to build anything together.
