Accounting & ERP

Connecting a website to the system that runs the business.

Most businesses already hold the truth about stock, pricing and customers in an accounting or ERP system. The website usually holds a copy of it, maintained by hand, that is wrong by varying amounts.

Stock & pricing Order push-back Trade accounts
The situation

Two systems, one version of the truth.

This is the integration that pays for itself fastest, because the manual work it replaces is both constant and error-prone. Somebody updates prices in the accounts package, then updates them again on the website, and the gap between those two moments is when a customer buys at last month’s price.

The direction matters. For most businesses the accounting or ERP system is authoritative and the website should follow it — stock levels, prices, product data flowing one way. Orders then flow back the other way, so sales appear in the accounts without anybody re-keying them.

Where it gets interesting is trade: customer-specific pricing, credit terms and account ordering all live in the back-office system, and reproducing those rules on the website by hand is how businesses end up quoting prices they cannot honour.

Able Web Services Ltd.UK web development
200+PROJECTS DELIVERED
140+CLIENTS SUPPORTED
15+YEARS ESTABLISHED
UKBASED & HOSTED

What we do

  • Bespoke websites and custom CMS development
  • Ecommerce, custom checkout and subscriptions
  • Web applications, portals and internal tools
  • API, CRM and business systems integration
  • Retained support, maintenance and managed hosting
  • White-label development for agencies

Working UK-wide — directly with businesses, and white label behind design and marketing agencies.

Discuss a project
What it involves

What typically moves, and which way.

Stock levels

From the back office to the website, usually on a schedule rather than live. The decision worth making early is what the site shows when stock is low or uncertain.

Prices and price lists

Including customer or group-specific pricing, so a trade customer logging in sees their own terms rather than list price.

Products and specifications

Descriptions, codes and attributes maintained once. For large catalogues this is usually the single biggest time saving.

Orders back

Website orders pushed into the accounting system as sales records, so the finance side does not re-enter them.

Customers and accounts

Linking a website login to the right account record, which is what makes account ordering and credit terms possible at all.

Invoices and history

Giving a logged-in customer their own order history and documents, pulled from the system that already holds them.

Straight answers

The things that decide whether this works.

Your product codes have to be consistent

The integration matches records on a shared key. If the same product has different codes in different places, that has to be resolved first, and it is usually a bigger job than the integration itself.

Scheduled is often better than live

Live sync sounds better and is sometimes worse — more load, more to go wrong, and rarely necessary for stock that changes a few times a day. We pick based on how fast your data actually moves.

Older systems vary enormously

Some on-premise ERP systems expose almost nothing. There is usually a route, but it is worth a short paid discovery to confirm what yours allows before anyone commits to a fixed price.

Related services

The wider picture.

Related work

Projects of a similar shape.

A lot of our work is delivered white label or under agreement, so these describe the problem and the approach rather than naming the client.

Questions

What people ask about back-office integration.

Will this work with our accounting package?
Most mainstream accounting and ERP packages have an API, and where one does not there is often a supported export route. The variable is usually your licence tier rather than the product, so the first step is confirming what your particular setup allows.
Can different customers see different prices?
Yes, and it is one of the more common reasons businesses do this. Prices can follow the account record in your back-office system, so a trade customer sees their terms once logged in. The detail worth getting right early is how your pricing rules actually work, because that drives the whole build.
What happens if the connection fails?
The website keeps serving the last known good data rather than showing nothing, and the failed sync is queued and reported. The alternative — a site that empties when the ERP is down — is a worse outcome than slightly stale stock.
We have tens of thousands of products. Is that a problem?
Not in itself, but it changes the approach. Bulk operations hit API rate limits that normal traffic never touches, so the sync has to be built to work through large volumes in batches rather than all at once.
Next step

Tell us which system holds the truth.

The accounting or ERP package, what the website currently duplicates, and what is being typed in twice. We will confirm what your system allows before quoting anything.