# Cross-Document Data Match Module

This guide is specific to Web SDK 2.0. If you are still using 1.x, you can find documentation [here](https://developer.incode.com/docs/web-sdk-reference). Contact your Incode Representative for upgrade information and check if you are a candidate for this upgrade.

Full rollout to all clients still TBD.

The Cross-Document Data Match module runs a backend comparison of OCR data across multiple captured documents (e.g., ID + proof-of-address) and flags inconsistencies. Fire-and-forget — completes after a minimum display duration so the user sees a confirmation spinner.

## Tag

`<incode-cross-document-data-match>` is a standard Web Component. Importing the UI subpath registers the custom element; the module is bundled with `@incodetech/web/flow` (no separate UI subpath import).

```ts
import '@incodetech/web/cross-document-data-match';
```

## Properties

| Property    | Type                           | Required | Description                                |
|-------------|--------------------------------|----------|--------------------------------------------|
| `config`   | `CrossDocumentDataMatchConfig` | ❌       | No options                                 |
| `onFinish` | `() => void`                  | ❌       | Called when comparison completes           |
| `onError`  | `(error: string) => void`     | ❌       | Called when an error occurs                |

## Configuration

The module takes no configuration:

```typescript
type CrossDocumentDataMatchConfig = Record<string, never>;
```

Comparison rules and inconsistency thresholds are configured server-side per tenant.

## State machine

`CrossDocumentDataMatchState` is a discriminated union over `status`:

| Status      | Description                                |
|-------------|--------------------------------------------|
| `idle`     | Initial state.                            |
| `processing`| Backend comparison in progress.            |
| `finished`  | Terminal — comparison completed.          |

The module deliberately holds the `processing` state for a minimum display duration so users see a confirmation spinner regardless of how fast the backend responds.