Laravel Uk Kyb Edge Laravel Package

Product Decisions This Supports

• Build vs. buy for UK company financial data. As of v1.1.0 the package covers two distinct jobs that would otherwise be two workstreams: (a) retrieving official filed-accounts PDFs from the UK registry and (b) converting a balance sheet into structured JSON. That combination is the expensive part of any UK underwriting, KYB, or SME-credit feature — the API call is trivial, the document pipeline and extraction layer are not. This is a credible "buy/assemble" answer to a question teams usually scope as a 1–2 quarter build.
• Roadmap sequencing for UK market entry. If the roadmap has "launch in the UK" behind an onboarding or credit-decisioning dependency, this shortens the critical path. It converts a data-acquisition problem into an integration task, which is usually a schedule win measured in weeks, not days.
• Feature bets it unlocks: automated affordability/credit pre-checks, supplier and counterparty risk scoring, monitoring and alerts on newly filed accounts, embedded finance and invoice finance eligibility, enhanced KYB during merchant or vendor onboarding, and portfolio-level financial health dashboards.
• Pricing and unit-economics decisions. Per-document vision extraction implies a marginal cost per company per refresh cycle. That is a pricing input, not just an engineering detail — it shapes whether monitoring is a paid tier, a rate-limited free feature, or an internal-only capability.
• Where it should not drive decisions: anything requiring real-time financials (filed accounts are periodic and lagged), group/consolidated structures, non-UK entities, or decisions that must be reproducible and auditable to a regulator without human review.

When to Consider This Package

Consider it when:

• The stack is Laravel/PHP and the team would rather adopt a maintained wrapper than own Companies House auth, pagination, retries, and document plumbing.
• The product need is structured financials for UK registered entities — balance sheet first, per the release notes — rather than a full registry data model.
• You need the PDF artifact as well as the numbers (audit trail, human review queues, customer-facing document display), which is what document() with streaming and CORS supports.
• You are pre-PMF or in a pilot and want to validate demand for a UK financial-data feature before committing headcount to extraction infrastructure.
• Your volumes are modest enough that per-document extraction cost is a line item you can model, not a threat to gross margin.

Look elsewhere or build when:

• You need jurisdiction coverage beyond the UK, or the full registry surface (officers, persons with significant control, charges, filing history) — the release notes describe a narrow, two-method slice.
• Decisions are regulated and must be explainable and deterministic. Vision-based extraction is probabilistic; without a confidence score, source-page citation, and a human-in-the-loop path, it is not a decisioning system of record. Expect to build reconciliation against the PDF regardless of vendor.
• Volumes are high or refresh cadence is aggressive — bulk re-extraction across a large book is where marginal cost and rate limits bite.
• You need contractual SLAs, uptime guarantees, or vendor support. A package release cadence is not a support contract.
• Legal has not cleared re-hosting and re-display of registry documents. document() enabling CORS is convenient for browser rendering but is also a distribution decision: confirm the licence terms for the underlying public data and your own terms of service before proxying PDFs to end users.
• The team is not on PHP, or the extraction output schema cannot be mapped to your domain model without a translation layer you would rather own.

Adoption caveats to validate before committing: whether financials() returns a stable, versioned schema; how extraction failures and low-confidence documents surface; rate limits and retry semantics in the updated UKBusinessClient Guzzle methods; and whether streaming is authenticated or open by default.

How to Pitch It (Stakeholders)

To the executive team: This package collapses two workstreams — official document retrieval and balance-sheet extraction — into an integration. For a UK launch it moves a data-acquisition dependency off the critical path and lets us test UK financial-data features with a small team instead of standing up a document pipeline and an extraction service. The trade-off is economic and regulatory, not technical: we pay per document extracted, so monitoring and bulk refresh need a pricing model before they become free features, and the extracted numbers are model-generated, so any lending or credit decision still needs a validation and human-review step. Frame the ask as "buy six to twelve weeks of schedule, then measure cost per company per refresh."

To engineering: It is a thin, idiomatic Laravel wrapper — a UKBusiness facade over a Guzzle-backed client — so integration cost is low and the surface is small. Two things to scope explicitly. First, financials() is a probabilistic extraction, not a parsed feed: we need schema validation, a confidence or failure signal, retry and fallback handling, and a stored link back to the source PDF so a human can verify. Second, document() streams registry PDFs with CORS enabled — decide deliberately whether that endpoint is public, authenticated, or internal-only, and cache documents rather than re-fetching. Treat the client as an external dependency: pin the version, wrap it behind our own interface so a swap is cheap, and build fixtures from real filings so extraction regressions are caught in CI rather than in a credit decision.