HubSpot–Business Central Integration Case Study: Order-to-Cash for a Industrial Distributor

Summary

Kestrel Industrial Supply distributes fastenings and fixings to contractors across four states, at roughly 2,400 order lines a month and an average order value of $3,180. Sales quoted from a price list exported nightly from Dynamics 365 Business Central into a spreadsheet, and re-exported when someone noticed it had drifted.

The engagement assigned a system of record per field, replaced the exported price list with a live availability and pricing read, and made order creation a single write from HubSpot into Business Central. Quote-to-order rework fell from 18 percent of orders to 4 percent, quotes issued against unavailable stock fell from 11 percent to under 1 percent, and the median time from accepted quote to confirmed order fell from 2.4 days to 3 hours.

Background: Two Prices for the Same Part

Business Central held the authoritative price. The spreadsheet held the price sales quoted from. Between the two sat a nightly export, a manual refresh nobody owned, and a contract pricing tier the export flattened.

The gap produced two distinct failures. Quotes went out below the current price, which finance corrected after acceptance and which the customer experienced as a price rise. And quotes went out for parts on backorder, because availability was a column in a file rather than a question asked at quote time.

Soh and Sia (2004) studied what happens when an organisation adopts packaged software whose built-in assumptions do not match how it works, and found the gap can be closed in only three ways: change the organisation, change the package, or build something at the boundary between them. Kestrel had chosen a fourth that is not a choice — a spreadsheet in the middle, owned by nobody, reconciled by whoever noticed.

The Audit

Two weeks against the portal, the ERP and eight weeks of order history produced four measurements.

Rework. 18 percent of orders required a price or availability correction after the quote was accepted. Each correction took a median 41 minutes across sales, finance and the customer.

Stale quoting. The exported price list carried a median age of 2.1 days at the point a quote was built from it, and 11 percent of quoted lines referenced stock that was unavailable at quote time.

Credit exposure. Credit hold status existed only in Business Central. Sales discovered a held account when the order was rejected, which happened on 6 percent of orders.

Identity. 340 of 1,910 customer records existed twice across the two systems, ordinarily as a trading name in HubSpot and a legal entity name in the ERP, with no shared key between them.

Identity Before Anything Moves

No two commercial systems share an identifier space. Wand and Wang (1996) treat an information system as a representation of the real world and define a data quality problem as a breakdown in the mapping between the two, and a customer existing twice is exactly that breakdown: one real business, represented twice, with a credit limit attached to one of them.

A dedicated property was created on the HubSpot company to hold the Business Central customer number, with unique values enforced at creation. Matching ran on that key alone. Where no key existed, the record was matched by hand against the ERP rather than by name, because name matching is what produced the duplicates.

Pipino, Lee, and Wang (2002) set out how data quality can be assessed in practice and give uniqueness a metric of its own rather than treating it as a by-product of careful work. The key is what makes it computable here: a weekly job now counts HubSpot companies with no ERP number, and the count is reported rather than assumed to be zero.

Field Ownership, Decided Once

Every field crossing the boundary was assigned an owner before any connector was configured.

Business Central owns price, availability, credit limit, credit hold status, payment terms and every tax determination. HubSpot owns the relationship: owner, lifecycle stage, activity history, quote state before submission. Nothing is owned by both.

The rule that made this hold is that HubSpot never writes a price. It reads one. A quote built in HubSpot requests current price and availability at build time and again at submission, and a difference between the two is surfaced to the seller rather than silently resolved.

The Build

Seven weeks, in four phases, using the Business Central OData v4 endpoints, a private HubSpot app for the write path, and a queue in the client's own Azure tenancy for order submission.

Phase one, identity. The customer number property was created and backfilled, and the 340 duplicates were merged against an agreed survivorship rule with an export taken first.

Phase two, read path. Price, availability, credit limit and hold status were exposed to HubSpot as read-only properties refreshed on demand at quote build and quote submission, rather than on a schedule. A scheduled refresh would have reintroduced the staleness the project existed to remove.

Phase three, write path. Order submission writes once, through a queue, with an idempotency key derived from the HubSpot quote identifier. Applying the same submission twice produces the same order rather than two.

Phase four, credit. Credit hold is read before a quote can be submitted, and a held account blocks submission with the reason shown. The check is in the flow rather than in a report.

Outcomes

Rework. 18 percent of orders before, 4 percent after. The residual is dominated by customer-initiated changes rather than by system disagreement.

Stale quoting. Quoted lines referencing unavailable stock fell from 11 percent to 0.6 percent, the remainder being stock that sold between quote build and submission.

Quote to confirmed order. Median 2.4 days before, 3 hours after. The former figure was dominated by the manual re-key into Business Central, which no longer exists.

Credit rejections. Orders rejected for credit hold fell from 6 percent to 0.2 percent, because the condition is now visible before submission rather than after.

Duplicate customers. 340 before, 0 at go-live, with the weekly unmatched count holding under 5 since.

Finance time. Order-entry time in finance fell by an estimated 22 hours a month, measured as the difference between orders re-keyed manually before and after.

What Resisted

Contract pricing tiers resisted. Business Central computes a customer-specific price from tier, volume break and any campaign discount, and reproducing that calculation in HubSpot would have created a second implementation that could drift from the first.

The mechanism was to stop trying. HubSpot requests a computed price for a customer and quantity rather than the inputs to compute one, so the arithmetic exists once. This is the module boundary Parnas (1972) described: neighbours depend on an interface rather than on internals, and a change to the pricing rules inside Business Central does not propagate outward.

The second difficulty was organisational. Sellers had built spreadsheets around the exported list, and those spreadsheets carried their own annotations. Umble, Haft, and Umble (2003) catalogued what determines whether an enterprise-system implementation succeeds, and training and sustained involvement appear in that list more reliably than any technical variable. The annotations were migrated into notes on the company record before the export was switched off, because switching it off first would have destroyed information nobody had written down anywhere else.

Limits

This does not prove that live reads outperform scheduled syncs in general. Kestrel's gain came substantially from price volatility and stock scarcity; a distributor with stable pricing and deep stock should expect a fraction of the same effect, and would pay the same latency cost at quote time for it.

The write path also assumes order volume that a queue can absorb. At 2,400 lines a month the queue is idle most of the day. A business writing orders continuously would likely need to consider throughput and back-pressure, neither of which was tested here.

Figures are drawn from the client's own order history and from HubSpot reporting. No holdout was run, and the improvement is not separated from a concurrent change in the sales team's compensation plan.

Conclusion

The integration is not a connector problem. Every figure above follows from two decisions taken before anything was connected: which system owns each field, and what identifies a customer across both. The connector can then move what it is told to move.

The general form is that a spreadsheet between two systems is not a workaround. It is a third system, with no owner, no schema and no reconciliation, and it may well be the one the business is actually running on.

References

Haug, Anders, Frederik Zachariassen, and Dennis van Liempd. 2011. "The Costs of Poor Data Quality." Journal of Industrial Engineering and Management 4 (2): 168–193. https://doi.org/10.3926/jiem.2011.v4n2.p168-193

Parnas, David L. 1972. "On the Criteria To Be Used in Decomposing Systems into Modules." Communications of the ACM 15 (12): 1053–1058. https://doi.org/10.1145/361598.361623

Pipino, Leo L., Yang W. Lee, and Richard Y. Wang. 2002. "Data Quality Assessment." Communications of the ACM 45 (4): 211–218. https://doi.org/10.1145/505248.506010

Soh, Christina, and Siew Kien Sia. 2004. "An Institutional Perspective on Sources of ERP Package–Organisation Misalignments." Journal of Strategic Information Systems 13 (4): 375–397. https://doi.org/10.1016/j.jsis.2004.11.001

Umble, Elisabeth J., Ronald R. Haft, and M. Michael Umble. 2003. "Enterprise Resource Planning: Implementation Procedures and Critical Success Factors." European Journal of Operational Research 146 (2): 241–257. https://doi.org/10.1016/S0377-2217(02)00547-7

Wand, Yair, and Richard Y. Wang. 1996. "Anchoring Data Quality Dimensions in Ontological Foundations." Communications of the ACM 39 (11): 86–95. https://doi.org/10.1145/240455.240479

Conflict of Interest

RevOps HQ is a HubSpot Solutions Partner and was engaged and paid by the client described.

Acknowledgments

Prepared by RevOps HQ.