Build vs Buy: Should You Build Your Own Catalog Integration Layer?

BoreaTech’s primer on what a procurement system is covers the buyer’s side of this problem: the system that ultimately needs clean, current catalog data to function well. This guide is about the layer that actually gets that data there: whether to build it yourself or buy something that already exists, worked through honestly rather than toward a predetermined answer. If the honest answer for your situation is “build,” this guide should get you to that conclusion just as readily as the other one.

What building actually means

Building a catalog integration layer usually gets scoped, at the start, as “write something that reads a supplier’s file and loads it into our system,” and that’s a real, achievable project for one supplier sending one clean CSV once. It stops being that project the moment a second supplier arrives in a different format, a third one needs EDI, and the first one’s file starts occasionally arriving with bad rows that need handling instead of crashing the import.

At minimum, a catalog integration layer that’s actually doing the job involves: ingestion parsers for whatever formats your suppliers actually produce, which in practice sprawls well past a single CSV template (see the range of formats that actually show up in production); validation logic that distinguishes a file worth rejecting outright from one worth accepting with flagged rows; mapping logic connecting supplier item data to your own item master and classification taxonomy; and, if you’re connecting to or from a procurement system rather than just loading a static file, at least one protocol integration (cXML or OCI PunchOut, or an EDI transaction set), each of which is its own project with its own edge cases, not a checkbox on a bigger one. “Building” means owning all of this end to end, not just the part that looks like the interesting engineering problem at the outset.

The parts teams underestimate

Four parts of this project consistently take longer than the initial estimate, and they show up in roughly the same order regardless of team size or how experienced the engineers doing the work are.

Protocol edge cases. Every PunchOut protocol has a set of failure modes that stay invisible until they’ve already produced a wrong number in production: OCI’s PRICEUNIT field silently defaulting to 1 and producing the wrong extended price, a decimal-separator mismatch turning a price into a completely different number, an index reused across two line items merging their data with no error raised anywhere. None of these show up in a working demo built against clean test data; all of them show up eventually against a real buyer’s real system, and “eventually” is usually after go-live, not before it.

Supplier onboarding. The engineering work of parsing a file is a small fraction of what actually maintaining supplier relationships around catalog data costs. Someone has to issue credentials, explain what format is expected, review a rejected submission, and communicate what needs to change, then do it again for every new supplier and every time an existing one’s export process changes on their end. This is an ongoing operational cost, not a one-time integration task, and it’s the part most likely to be scoped as “we’ll figure it out” rather than actually staffed.

Ongoing catalog refresh. A catalog isn’t loaded once. Prices change, items get discontinued, new items get added, and the specific ways catalog data degrades across repeated refreshes (near-duplicate SKUs from an unhandled part-number change, classification drift, stale image links) are exactly the failure modes that don’t show up in a single successful initial load and instead accumulate quietly across every refresh that comes after it.

Per-buyer or per-system variance. If your catalog needs to reach more than one procurement system, each one is a separate integration with its own field conventions, not a configuration flag layered onto the first one. A cXML integration built for one platform doesn’t transfer cleanly to an OCI-based one, and even two buyers on nominally the same protocol can have their own quirks in which fields they expect populated. A team that budgeted for “one integration” and ends up needing three has usually underestimated by more than triple, because the second and third integrations have to be maintained alongside the first rather than replacing it.

When building is genuinely right

Building is the right call more often than a vendor’s pitch deck will admit, and it tends to be right under a specific, recognizable combination of conditions rather than as a general philosophy.

A small, stable supplier count. A handful of suppliers (low double digits, sending catalog data on a predictable cadence) is a manageable scope for a lightweight, purpose-built integration, and the operational overhead of supplier onboarding at that scale is genuinely small. The fan-out problem that makes catalog integration expensive is a function of supplier count and format diversity, and neither one is large here.

One procurement system, with no near-term plan to add a second. If every catalog only ever needs to reach one system, a bespoke integration scoped tightly to that one system’s actual requirements can be simpler and cheaper than a general-purpose platform built to handle protocols and systems you’ll never use. Generality has a cost, and paying for flexibility you don’t need isn’t a good trade.

An existing integration team with spare capacity and real protocol experience. If the engineers who would build and maintain this already exist on payroll for other reasons, already understand EDI or cXML from prior work, and have room in their roadmap, the marginal cost of building is close to zero compared with a team that would need to be hired or trained from scratch. This condition is doing most of the work in this case: the same build looks very different in cost if it requires net-new headcount rather than existing slack.

A catalog that changes rarely. A supplier catalog that’s genuinely stable (infrequent price changes, a slow rate of new or discontinued items) reduces the ongoing refresh burden that’s usually the expensive, underestimated part of a build. A once-a-quarter manual review process is a legitimate answer for a catalog that doesn’t move much, and building lightweight tooling around that cadence is a reasonable scope rather than an underinvestment.

A genuinely non-standard requirement a general platform won’t fit. Some businesses have a classification scheme, a pricing model, or a fulfillment constraint specific enough that a generic catalog platform’s data model doesn’t accommodate it without a workaround that ends up as awkward as building it yourself would have been. When that’s actually true, building gets you a system that models your business, instead of one that models a vendor’s median customer.

When it is not

The same conditions in reverse are the honest signal that buying is the better call, and they tend to show up together as a pattern rather than as five independent factors.

A growing supplier count compounds the onboarding and format-diversity burden faster than most teams expect going in: the tenth supplier isn’t proportionally harder than the first, but the hundredth arrives on top of ninety-nine others’ catalogs that still need refreshing, monitoring, and correcting, and that maintenance load doesn’t pause while the team builds integration ninety-one. Supporting more than one procurement system multiplies the protocol-maintenance burden the same way, since OCI and cXML don’t share a wire format or a set of edge cases even though both solve the same underlying problem: a team maintaining both is really maintaining two systems, not one system with two settings.

No dedicated integration team, or one with other priorities, is the condition that turns a reasonable-sounding build estimate into a project that stalls. Catalog integration doesn’t get easier to deprioritize once it’s half-built; a partially working ingestion pipeline that occasionally corrupts a price is often worse than no pipeline at all, because it looks done to everyone who isn’t looking closely. And a catalog that refreshes frequently (weekly or more often, across a supplier base that’s actively changing pricing and assortment) turns the ongoing-maintenance cost from a periodic task into a standing operational commitment, which is the hardest part of a build to estimate accurately up front, because it doesn’t show up until well after the initial project is declared finished.

A cost framing that is not a sales pitch

The honest cost comparison isn’t “engineering hours to build” versus “license cost,” because that comparison almost always favors building on paper and rarely holds up in practice. The comparison that actually predicts outcomes is the fully loaded cost of build-and-maintain against the fully loaded cost of buy-and-configure, evaluated over a multi-year horizon rather than the first quarter.

On the build side, that means counting the initial integration work, the ongoing maintenance every protocol change and new supplier requires, the opportunity cost of engineers doing this instead of something else, and the risk of the person who understands the system leaving before it’s documented well enough for someone else to take over cleanly. None of these show up in an initial estimate that only counts the hours to get a first version working.

On the buy side, it means counting the license cost honestly against what it actually replaces, without assuming it replaces everything: a platform doesn’t remove the need for someone on your team to own supplier relationships, review flagged data-quality issues, and make the judgment calls a taxonomy or mapping tool can’t make on its own. Buying converts a variable, growing engineering cost into a more predictable one, but “predictable” isn’t the same as “requires no ongoing attention,” and treating it that way is how a platform ends up underused relative to what it’s capable of.

The honest version of this comparison usually favors buying once supplier count, protocol count, or refresh frequency cross a threshold specific to your own team’s capacity; it favors building below that threshold. Neither direction is universally correct, which is exactly why the calculation is worth doing explicitly for your own numbers rather than defaulting to whichever answer matches how the team already thinks of itself.

Where SupplierForge fits

For teams whose build-versus-buy calculation lands on buy: SupplierForge covers ingestion across CSV, Excel, structured feeds, direct API, SFTP and EDI; item mapping and categorization; ongoing catalog health and data-quality monitoring; and procurement-system integration through native PunchOut, cXML and OCI, with protocol translation across cXML, OCI and EDI available through the separately licensed PunchOut Gateway. None of that changes the calculation above: it’s an input to the buy side of it, not a reason to skip doing the comparison for your own supplier count, protocol mix, and team capacity. See the feature set for the full breakdown, and how the pieces connect end to end for how ingestion, mapping, and integration fit together as one pipeline rather than separate tools.