Corroborate the attribution against name, VAT identifier, country and address

[jbagsik]

Parent

#21

What to build

Everything else the document says about the buyer — name, VAT identifier, country, address — is
checked against the matched customer and only ever flags. A divergence marks the document as
needing review; it never changes or discards the attribution.

That asymmetry is the point. The identifier is exact, the rest is not. A reviewer who is shown "the
system proposed customer X, but the printed name doesn't fit" can judge the case; a reviewer handed a
bare "no match" has to re-derive it by hand.

The checks are tuned for specificity, not sensitivity. A wrong attribution requires a wrong
identifier, which puts an unrelated party's name on the document — so the check only has to catch
total strangeness. A false alarm costs manual work on every document and trains reviewers to dismiss
warnings, which is worse than no check at all.

Once this lands, a document with a clean, consistent match progresses to the validated state
automatically for the first time.

Acceptance criteria

• A name corroborates if it shares at least one significant token (four characters or more, legal
  forms treated as stop words) with any known name of the matched customer or its company.
  Normalisation: lowercase, fold diacritics, strip punctuation.
• A renaming that keeps a distinctive token still corroborates; a wholly unrelated party name does
  not.
• VAT identifier and country code are compared only when present on both sides. Absent on
  either side is never a divergence — the field's configured priority decides whether that becomes
  a review case.
• The parsed buyer address is checked for existence among the matched customer's company's
  known addresses, filtered by address role. No address reference is persisted anywhere.
• The address check runs only after a successful customer match, never otherwise.
• Every row of the cascade in Resolve documents to a Customer by buyer identifier, with corroboration and review #21 is observable at the validation entry point,
  including: identifier matches while the name diverges ⇒ attribution kept, needs review;
  soft-deleted or inactive customer ⇒ needs review; customer without a company ⇒ needs review.
• Each check records what it matched against, so a reviewer can see the proposal rather than just
  the verdict.
• A document with a clean, consistent match reaches the validated state without human action.
• Covered through the field validator's public validate entry point.

Blocked by

• Attribute documents to a Customer via the buyer identifier, derive the company #24 — there is nothing to corroborate until a customer is attributed.

[jbagsik]

Done

Corroboration of an attributed Customer against buyer name, VAT, country and address is in place. Identifier attribution is unchanged: divergences only flag needs_review and never clear or rewrite customer_id / derived company_id.

What shipped

• Support\AttributionCorroborator — significant-token name match (≥4 chars, legal-form stop words; lowercase / diacritic fold / punctuation strip); VAT & country compared only when both sides present; address existence among the matched company’s role-filtered addresses (AddressFingerprint); no address FK persisted
• Wired through InvoiceFieldValidator::validate() (no public matcher/corroborator seam)
• Soft-deleted / inactive customer and missing/ambiguous company derivation → customer_number = needs_review while attribution is kept
• Clean, consistent match can reach review_status = Validated without human action (parsed treated as clean; no-source stubs → not_applicable)
• Config: e-billing.corroboration (name_min_token_length, name_legal_form_stop_words, address_roles)
• Coverage in tests/Feature/InvoiceFieldValidatorCustomerAttributionTest.php

Parent cascade (#21)

Observable at the validate entry point: identifier + name diverge ⇒ attribution kept + review; soft-deleted/inactive ⇒ review; customer without company ⇒ review; clean path ⇒ Validated.

Closes the corroboration slice of #21. Portal visibility still must gate on customer_id + validated status (not company_id alone) — out of scope here.