Your supplier portal finds a company record, fills in the name and address, and marks the profile complete. Months later, a background synchronization changes the name shown on an approved contract. Nobody approved a new counterparty. The application simply treated the latest register response as permission to rewrite the business record.
For UK procurement teams commissioning a supplier portal, Companies House integration is useful precisely because it can reduce repetitive lookup work. The mistake is to merge observation and approval. Public company information, the supplier's own declarations and the organization's accepted commercial record need a clear relationship without becoming one mutable block of text.
The APIs provide records and changes, not your procurement policy
The official company-profile endpoint retrieves basic company information by company number and returns an ETag for the resource. The streaming API overview describes access to changes and the use of a timepoint to connect a snapshot with a stream.
Those capabilities can support a current supplier-information view. Our recommendation is to turn meaningful changes into reviewable events rather than silently replacing approved data. The precise review policy belongs to the buyer and its responsible advisers; it is not encoded automatically in a company-profile response.
This distinction also keeps the product honest. A badge saying registry information retrieved should not become identity verified or supplier safe unless the organization has defined and completed the additional checks those labels imply.
Give the legal entity and the trading relationship separate records
A company number should identify the company record within the relevant source. The procurement relationship needs its own identity: who buys, what is supplied, which contracts apply and who owns the relationship internally. One company may have several relationships, and one supplier group may contain multiple legal entities.
Keep registered-office information separate from delivery sites, service locations and invoice-routing instructions. These fields can legitimately differ. If the software copies the registered office into every address field, a routine register change can disrupt goods receiving or accounts payable.
Store the original supplier submission alongside the normalized record and the approval decision. An auditor or operations manager should be able to reconstruct what the reviewer saw at the time. Showing only today's registry response cannot explain a decision made several months earlier.
Decide which changes deserve attention
Not every updated field needs an urgent task. Build a review policy with the team that owns procurement. Changes affecting the entity relationship may deserve review, while a formatting adjustment may only need an observation in the history. The policy should be versioned so that later changes in your rules do not rewrite the meaning of earlier decisions.
An illustrative case: a supplier's registered name changes while its company number remains the same. The portal can preserve the previously approved contract label, show the newly observed name and create a focused review. The reviewer decides which operational records should change and records the reason.
By contrast, a supplier asking to invoice through a different company number raises a different question. It is not merely a spelling correction. The software should route it through the organization's counterparty-change process rather than allowing a profile editor to replace the key behind existing purchase orders.
Keep bank details outside the register-refresh shortcut
Teams sometimes extend autofill into an unsafe assumption: if company information matches, every new instruction from a contact must also be trusted. Design payment-detail changes as a separate controlled workflow with the verification steps your finance team requires.
A Companies House integration should not be represented as confirmation of a bank-account change. Likewise, a contact's access to a portal does not prove they are authorized to change every field. Permissions can distinguish a supplier employee submitting a request from an internal reviewer accepting it.
The interface can make this separation simple. Let the supplier propose a change, display the pending request and keep the currently approved payment instruction visible to authorized staff. Avoid an ambiguous state where the screen shows the new value but downstream systems still use the old one.
Plan for missed changes and repeated changes
A streaming connection can stop. An import can fail after some records have been written. A deployment can restart a consumer. The proposal needs to explain how processing position is stored and how the system reconciles after a gap, rather than assuming the connection will remain uninterrupted.
Record the identity of each processed event or relevant version so that replay does not create duplicate review tasks. At the same time, avoid deduplicating all changes for a company into one permanent key: a later genuine update must still be noticed. Test the distinction with realistic sequences.
Expose the freshness of the registry view to operators. If the connection is behind, show that state without pretending the suppliers themselves are invalid. A data-source outage is an integration problem, not evidence of a counterparty problem.
A procurement pilot should finish at a business decision
Choose a small set of existing suppliers with known historical changes. Demonstrate initial matching, a changed observation, a review decision and a downstream update. Include a rejected match and a supplier with an address that differs from its registered office.
Companies House provides guidance for API testing, distinguishing read-only public-data APIs from APIs that create or change filings. A supplier-information pilot should remain within the read-only scope it needs. It does not require writing changes to the public register.
Measure manual lookup time, unresolved changes and the effort required to reconstruct an approval. A successful pilot leaves the buyer with a clear decision trail and defined recovery process. It should also reveal which data-cleaning work remains before a wider rollout.
Our software discovery guide helps turn this workflow into an initial scope. The project handover guide explains the operational assets the buyer should receive. TuniCyberLabs can connect the register, supplier portal and procurement systems through custom software development. Share the supplier change your team currently handles by email and we can define an accountable first integration.