We create digital solutions that work for businesses
A manufacturer's catalog goes stale faster than it seems. A month after launch everything looks fine; three months in the prices are wrong, several items have been discontinued and stock does not match the warehouse. A manager spends the day answering "is this still available?", and a purchasing manager who saw an old price stops trusting the whole catalog. ERP integration removes this problem technically: the site stops being a second database someone has to update by hand.
The "a manager updates prices once a week" scheme looks workable right up to the first crunch. Then simple arithmetic kicks in: a manufacturer has a thousand items, prices change in batches, stock changes daily, and manual work physically cannot keep up.
Then it gets worse. A catalog nobody trusts stops being used by the managers themselves: it is easier to email the client a current Excel file. The site formally exists while sales go around it.
So the question is not staff discipline but architecture. Data has to live in one place and propagate automatically — then forgetting becomes impossible.
An exchange is not "export everything". Usually four groups of data travel, and each has its own update frequency.
Product range: name, article number, category, unit of measurement, specifications, shipment multiples. Changes rarely, updates once a day.
Prices: base and by client type — retail, wholesale, dealer, personal. Updated on schedule or immediately after a change in accounting.
Stock: by warehouse, often split into "in stock / to order / expected". The most common frequency is several times a day, or real time.
The return flow: quote requests and orders from the dealer account come back into accounting as documents. This is the part usually forgotten, and it saves the most time.
Technically there are several options, and the choice depends on the state of your system.
Built-in exchange. Many accounting configurations have a built-in mechanism for exchanging with a website in a standard format. The simplest route if the configuration is typical and not heavily customised.
Via API or web service. A more flexible option: the site queries the system directly and takes exactly what it needs. Suits cases where the exchange has to be frequent or two-way.
Via an intermediate file. Accounting exports XML or CSV to a folder or cloud on schedule and the site picks it up. Simple, reliable and requiring no external access to your server — often the decisive argument for a security team.
If there is no accounting system yet, the starting option remains scheduled Excel import: you maintain the file in the usual form and the site picks up the changes. Later the source changes while the catalog structure stays.
Developers usually say "we will connect it in a week", and that is true only of the channel itself. The bulk of the work is in mapping structures.
Typical places where things break: categories are named differently in accounting than they need to be on the site; specifications sit in one text field instead of separate ones; a single item has several article numbers; units of measurement differ — tonnes in accounting, linear metres on the site; photos are stored outside the system.
So the realistic plan looks like this: first export and analyse the product range, then build a field mapping table, and only then set up the exchange. Skipping the middle stage is not an option — it determines whether the catalog looks like a catalog rather than a database dump.
How the catalog itself should be built and why B2B needs quote requests we covered in B2B catalog: quote requests instead of a cart.
Accounting knows the article number, price and stock but does not know how to sell. Descriptions, applications, benefits, photos from sites, certificates — none of that is usually in the system, nor should it be.
The working scheme is hybrid: technical fields are pulled from accounting and overwritten on every exchange, while marketing fields live in the site's admin panel and are never touched by the exchange. Then a manager can add a category description or a drawing without fearing the next export will wipe it.
This rule should be established at the start: a source of truth is defined for every field. Otherwise in a month someone will ask why all the descriptions vanished.
Exact stock figures are rarely shown in B2B — it is sensitive information, and competitors read your site too. But hiding it entirely is not right either: the purchasing manager needs to know whether the goods exist now.
The practical compromise is statuses instead of numbers: "in stock", "to order, N days", "expected". Dealers in their account can see exact quantities while guests see statuses.
The key is that these statuses update automatically. An "in stock" label on an item that has been unavailable for two months is worse than no label at all.
Real time sounds attractive, costs more and is not needed by everyone. Practical benchmarks are these.
Product range and specifications — once a day, at night. Prices — once a day, or after every change in accounting if they move often. Stock — several times a day for most manufacturers; real time makes sense when an item can sell out within an hour.
Orders and quote requests — immediately, with no delay: here speed directly affects the deal.
It is also worth providing a manual exchange trigger button in the admin panel. That saves the day in "we changed the price and need it live now" situations.
Any integration eventually breaks: a configuration was updated, a password changed, the accounting server was switched off. The question is not whether it will happen but whether you will find out.
The minimum set of safeguards: an exchange log with the result of every run; an email alert if the exchange fails twice in a row; a rule of "if it did not update, keep the previous data" rather than emptying the catalog; and a last-updated timestamp in the admin panel so it is visible at a glance.
That last detail matters especially: without it the catalog can show old prices for two weeks and nobody will notice. It is the same logic as with backups: the question is not whether you will need them but whether you find out in time — we covered that in website backups.
Three effects show up quickly. Managers stop spending hours on "let me check and call you back" — the site matches accounting. "Send us the current price list" emails disappear, because the file is generated from the catalog at download time. And statistics appear: what gets viewed, what ends up in requests, and what sits without movement.
Plus something less obvious: when the catalog can be trusted, managers start using it themselves — sending clients a link to an item instead of emails with attachments. How to measure the site's return overall is described in how to calculate a website's return.
What building such a site includes is collected on the page about B2B websites for manufacturers.
The most common reason deadlines slip is not technical. Data in accounting is entered the way the finance team finds convenient rather than the way a catalog needs it. So before connecting anything it is worth going through the range and tidying it up — that is work nobody but you can do.
The minimum: item names in human form rather than internal codes; specifications split into separate fields instead of one text blob; categories buyers actually search by; consistent units of measurement; duplicates and long-discontinued items removed.
This can run in parallel with site development, and that is usually how we work: while design and markup are under way, your accounting specialist cleans the range against our checklist. By the time the catalog is ready to receive data, the data is fit to be received.
Yes, and that is the most common case — typical configurations barely exist. Instead of the built-in exchange we simply build a custom export in an agreed format. At the briefing we need the configuration version and a contact for your accounting specialist: they build the export on their side, we build the intake on the site.
Properly configured, no. Exports are scheduled at night or made incremental — only changes since the last exchange travel rather than the whole database every time. The load on the system in that mode is imperceptible.
Nothing, provided a source of truth is defined for each field at the start. Technical data is overwritten from accounting, marketing data is not. This is configured once and then works by itself.
The exchange channel itself — a few days. Mapping structures and cleaning up the product range — from a week to a month depending on the state of the data. So the honest answer is: if the range is in order, integration runs alongside site development and adds no time; if not, the data has to be tidied first.
Yes, and for many that is the right path. You start with scheduled Excel import, and when accounting is ready we swap the data source. The catalog structure, filters and pages stay the same — nothing has to be rebuilt.
ERP integration is needed not for the technology's sake but so the catalog stops lying. Product range, prices by client type and stock travel one way, while quote requests come back. The bulk of the work is not the exchange channel but mapping structures and cleaning the range. Keep marketing fields on the site's side, set up exchange monitoring — and the catalog will stop going stale without anyone's involvement.
Design & UI/UX
SEO
SEO
Analytics and Conversion
Let’s create something amazing together Leave your number — we will call you back within 15 minutes during working hours.
We will call you back shortly.
