Appearance
Checks
Endpoints for interacting with EyeDP checks
Get case checks
Returns all the checks performed on a case.
| Endpoint | /api/cases/{caseId}/checks |
|---|---|
| Method | GET |
Response
json
[
{
"id": 206,
"createTs": "2025-08-20T15:51:17.303",
"checkName": "financial-vulnerability",
"documentIds": []
},
{
"id": 205,
"createTs": "2025-08-20T15:51:17.243",
"checkName": "kyc",
"documentIds": []
},
{
"id": 204,
"createTs": "2025-08-20T15:49:41.987",
"checkName": "content-validation",
"documentIds": []
}
]Details
| Field | Description |
|---|---|
| Id | Id of the check used to get the check results |
| CreateTs | Timestamp of the check |
| Check name | Name of the check |
| documentIds | If a check is on any of the case documents they will show up here |
Check: Tamper detection
Returns tamper detection check results for a document. This check is triggered as soon as a document is uploaded to EyeDP.
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
json
{
"id": 1234,
"checkName": "tamper-detection",
"checkLabel": "Tamper Detection",
"checkDescription": "Tamper analysis on a provided document.",
"createTs": "2026-01-26T11:13:05.8",
"tamperDetectionResponse": {
"riskRating": "High",
"riskRatingLabel": "Pdf processed by editor",
"riskRatingDescription": "Document was processed using editing software",
"results": [
{
"title": "Declared document language is English (United Kingdom)",
"description": "The creator of this document declared English (United Kingdom) as the language of the document's content."
},
{
"title": "Saved in Microsoft Word",
"description": "The document was processed and saved in Microsoft Word - document tool from Microsoft."
},
{
"title": "No difference between creation and modification date",
"description": "The creation and modification dates in this document's metadata are the same, suggesting no updates were made after the file was first created."
}
]
}
}The tamper detection response contains an overall risk rating with details stored in the results section. The following table describes the fields in more depth.
| Field | Description |
|---|---|
| Risk Rating | This is the overall risk rating of the check. It is determined by your risk configuration set in the EyeDP portal. It can be the following values: Low, Medium, High or Informational |
| Risk Label | The label given to the risk |
| Risk Description | A brief high level explaination of the risk |
A full list of the possible risk labels can be found in the EyeDP portal config page.
Results
Tamper detection runs a lot of different check on the document. The results section give more details on the findings.
| Field | Description |
|---|---|
| Title | Short title of the tamper check |
| Description | Detailed description with more information of the tamper check |
Extra Metadata
There is extra metadata available when a query parameter of includeMetaData with a value of true is provided.
e.g. /api/cases/123/checks/123?includeMetaData=true
Enabling the metadata returns Document quality, document metadata and metadata on the tamper detection results.
Quality
Quality of the document resolution has three possible values: HIGH_QUALITY, LOW_QUALITY or NOT_RELEVANT_DOCUMENT
json
"quality": "HIGH_QUALITY"Document metadata
json
"documentMetadata": {
"producer": "Adobe PDF library 11.00",
"creator": "Adobe Illustrator CC 2014 (Macintosh)",
"creationDate": "2019-06-01T10:35:36-04:00",
"modificationDate": "2019-06-01T10:35:36-04:00"
}Bounding boxes
Bounding boxes are available for results such as Suspected Content Tampering. These are to show locations where tampering is suspected.
json
{
"title": "Suspected content tampering",
"description": "Some characters in the image differ from the typical visual patterns found elsewhere in the document. This may indicate digital manipulation or tampering.",
"code": "grp_content_tampering_suspected",
"type": "RISK",
"category": "modification",
"boundingBoxes": [
{
"pageId": 0,
"x": 405,
"y": 103,
"width": 4,
"height": 7
},
{
"pageId": 0,
"x": 446,
"y": 103,
"width": 5,
"height": 7
}
]
}Results Metadata
Some results such as 'Document has unexpected metadata' includes specific metadata to help explanations.
json
{
"title": "Document has unexpected metadata for this issuer",
"description": "The metadata, such as the document's creator, producer, or PDF version, differs from what is typically seen in documents from this issuer.",
"code": "anomalous_metadata",
"type": "RISK",
"category": "anomalous_metadata",
"boundingBoxes": [],
"resultData": [
{
"columnNames": [
"Key",
"Value"
],
"data": [
"PDFVersion",
"PDF-1.7"
]
}
]
}Check: Content validation
This type of check runs a set of rules against the contents of uploaded documents and the case itself. This check is triggered as soon as a document is uploaded to EyeDP.
Rules will either compare the data on a document with the case, or compare each document on the case with the other documents for consistency. We call these "Doc V Doc" rules.
The endpoint is the same, but the response will adapt depending on the type of check.
The rules enabled in your setup can be accessed through the Portal: https://portal.eyedp.com
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response - Rules
If any of the rules fail the endpoint will return the rules with the status as 'Failed':
json
{
"id": 230,
"createTs": "2025-08-22T13:45:25.01",
"contentValidationResponse": {
"rules": [
{
"status": "Failed",
"name": "Name",
"riskRating":"High",
"description": "Checks document name against Case name",
"documentIds": [
960
]
},
{
"status": "Failed",
"name": "Date of Birth",
"riskRating":"High",
"description": "Checks the document date of birth against Case date of birth",
"documentIds": [
960
]
}
]
}
}Passed rules will return a status of 'Passed':
json
{
"id": 230,
"createTs": "2025-08-22T13:45:25.01",
"contentValidationResponse": {
"rules": [
{
"status": "Passed",
"name": "Joint account",
"description": "The platform will flag an alert if the document is in joint names",
"documentIds": [
960
]
}
]
}
}Details - Rules
The rules of the check contains the following fields
| Field | Description |
|---|---|
| Status | Status can be one of 3 options: Pending, Passed or Failed. Pending only appears while the rule is executing. Generally this is very quick so you probably won't see it. You're most likely to see it as either Passed or Failed which are the results of the rule. |
| Name | Short name of the rule |
| RiskRating | The risk rating according to your risk configuration. Possible values are: Low, Medium or High |
| Description | Longer more detailed description of the rule |
| DocumentIds | The documents involved in the rule. Rules that compare document contents like a Name against the case will only show a single Id. If the rule is looking at trends across documents all the document ids will be included. |
Response - Doc V Doc Rules
json
{
"id": 6808,
"checkName": "content-validation",
"checkLabel": "Content Validation",
"checkDescription": "Check the information contained within a document against public sources and other documents stored in the case.",
"createTs": "2026-03-05T14:14:54.453",
"contentValidationResponse": {
"docVDocRules": [
{
"id": 11,
"snapshotId": 1508,
"ruleId": 2,
"resultId": 3,
"operationId": 6808,
"checkText": "Different Date of Births were found across the documents",
"rule": {
"id": 2,
"name": "Date of Birth",
"shortDescription": "Compares the Date of Birth across documents",
"description": "Compares the Date of Birth across documents",
"riskFactorId": 73,
"documentTypes": [
"Passport",
"Driving Licence",
"Other"
]
},
"result": "Flagged",
"riskRating": "Medium",
"entries": [
{
"id": 448,
"docAId": 2098,
"docBId": 2102,
"docAType": "Driving Licence",
"docBType": "Driving Licence",
"resultId": 3,
"result": "Flagged",
"checkText": "Compared 29/01/1981 to 05/01/1964"
},
{
"id": 449,
"docAId": 2098,
"docBId": 2103,
"docAType": "Driving Licence",
"docBType": "Passport",
"resultId": 3,
"result": "Flagged",
"checkText": "Compared 29/01/1981 to 18/01/1963"
},
{
"id": 450,
"docAId": 2098,
"docBId": 2106,
"docAType": "Driving Licence",
"docBType": "Driving Licence",
"resultId": 2,
"result": "Matched",
"checkText": "Compared 29/01/1981 to 29/01/1981"
},
...
]
},
...
}
]Details - Doc V Doc Rules
| Field | Description |
|---|---|
| Id | The ID of the rule execution |
| CheckText | Detailed summary of the result |
| Entries | A collection of comparisons performed when running the rule. See the Doc V Doc Rule Entries section |
| OperationId | The ID of the associated operation for this rule exeution |
| ResultId | The internal ID of the result. A text version is in Result |
| Result | A text version of the result. |
| RiskRating | The risk rating according to your risk configuration. Possible values are: Low, Medium or High |
| RuleId | The ID of the Doc V Doc Rule that this resultset belongs to |
| Rule | The Doc V Doc Rule this resultset ran against. See the Doc V Doc Rule section |
| SnapshotId | The Snapshot ID of the case that the rule was executed against |
Doc V Doc Rule
| Field | Description |
|---|---|
| Id | The ID of the rule |
| Description | Longer more detailed description of the rule |
| Name | The name of the rule |
| ShortDescription | A short description of the rule |
| RiskFactorId | The ID of the Risk Factor that this rule raises when flagged |
| DocumentTypes | A list of the Document Types that this rule runs against |
Doc V Doc Rule Entry
| Field | Description |
|---|---|
| Id | The ID of the rule run entry |
| DocAId | The ID of Doc A |
| DocBId | The ID of Doc B |
| DocAType | The type of Document A |
| DocBType | The type of Document B |
| ResultId | The internal ID of the result. A text version is in Result |
| Result | A text version of the result |
| CheckText | Detailed summary of this entry |
Check: KYC
Returns KYC check results for a case.
Case requirements
| Property | Notes |
|---|---|
| Dob | DOB is required to run eKYC (all three, DOBDay, DOBMonth, DOBYear) |
| Fullname | Fullname will work if supplied, the check separates into first & last name splitting on space |
| GivenNames & Surname | If Fullname isn't supplied a minimum of GivenNames has to be supplied |
| Address | Has to be split address cannot use FullAddress |
| CaseType | Has to be Individual |
This check is only triggered through executing workflows. Please see the workflows page.
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
json
{
"id": 241,
"createTs": "2025-08-22T15:40:21.55",
"kycResponse": {
"decision": "Pass",
"rules": [
{
"ruleId": "7603",
"ruleName": "V_EId_2PSNAx",
"ruleScore": 1,
"ruleText": "2+ Primary or Secondary Name and Address (DoB agnostic)"
},
{
"ruleId": "6710",
"ruleName": "V_EId_1ScNAx",
"ruleScore": 1,
"ruleText": "At least one Primary or Secondary Data Source, with a name and address"
}
],
"matches": [
{
"matchType": "Name Only",
"matchKeyValues": [
{
"key": "Primary",
"value": 0
},
{
"key": "Secondary",
"value": 0
}
]
},
{
"matchType": "Name and DOB",
"matchKeyValues": [
{
"key": "Primary",
"value": 0
},
{
"key": "Secondary",
"value": 0
}
]
},
{
"matchType": "Name and DOB",
"matchKeyValues": [
{
"key": "Primary",
"value": 0
},
{
"key": "Secondary",
"value": 0
}
]
},
{
"matchType": "Name and Address",
"matchKeyValues": [
{
"key": "Primary",
"value": 1
},
{
"key": "Secondary",
"value": 0
}
]
},
{
"matchType": "Name, Address and DOB",
"matchKeyValues": [
{
"key": "Primary",
"value": 5
},
{
"key": "Secondary",
"value": 1
}
]
}
]
}
}Response breakdown
Decision
The overall decision of the KYC check. Possible values are:
| Result | Description |
|---|---|
| Pass | We've been able to verify the individual's identity successfully |
| Refer | We've only been to partially verify the individual's identity. Further review is required. |
| Fail | No verification of the person's identity could be found. |
Rules
Rules are ran on the matches found in the search. The outcome of the rules determines the overall KYC decision. A rule score of 1 means the conditions of the rule has been matched. A score of 0 means the conditions have not been matched.
EyeDP does have a standard ruleset. However, the exact rules you have will different depending on configuration.
The standard config is:
| Result | Conditions |
|---|---|
| Pass | 2+ Name+Address matches found from Primary or Secondary sources |
| Refer | At least one Name+Address match from a Primary or Secondary source |
Matches
The number of matches found in each data source category. They're broken down by match type such as 'Name and DOB' where the individual's name and dob have been found on a data source together. Or 'Name, Address and DOB' where every searched part of the individual has been found.
Primary match
These are authoritative, direct, and often government-verified records that provide a high level of confidence in an individual's identity. Examples are Electoral Register and Credit/Financial information.
Secondary match
These are generally less authoritative or easily obtained records that support or corroborate the information found in primary sources. Examples are Mobile phone data or utility records.
Check: Financial vulnerability
Returns Financial Vulnerability check results for a case.
Case requirements
| Property | Notes |
|---|---|
| Dob | DOB is required to run FinVul (all three, DOBDay, DOBMonth, DOBYear) |
| Fullname | Fullname will work if supplied, the check separates into first & last name splitting on space |
| GivenNames & Surname | If Fullname isn't supplied a minimum of GivenNames has to be supplied |
| Address | Has to be split address cannot use FullAddress |
| CaseType | Has to be Individual |
This check is only triggered through executing workflows. Please see the workflows page.
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
json
{
"id": 242,
"createTs": "2025-08-22T15:40:22.69",
"finvulResponse": {
"decision": "Fail",
"rules": [
{
"ruleId": "C6506",
"ruleName": "V_PI_CCJ_5000",
"ruleScore": 0,
"ruleText": "One or more active CCJs with a total value over £5000 found"
}
]
}
}Check: Bank account verification
Returns Bank account verification check results for a case.
This check is triggered as soon as a document is uploaded to EyeDP.
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
json
{
"id": 223,
"createTs": "2025-08-22T13:45:24.37",
"bavResponse": {
"decision": "Pass",
"rules": [
{
"ruleId": "CNS1004",
"ruleName": "BAV_Acc_Age_0_30_Days",
"ruleScore": 0,
"ruleText": "Data has been found to indicate that the account was opened in the last 30 days"
}
]
}
}Check: AML
The AML check searches the case against watchlist, sanctions, politically exposed people and adverse media datasets.
The check includes the Name, DOB and Country of the case in the search.
The check is synchronous and can be executed through the AML workflow
Request options
Options can be provided when executing the workflow.
| Name | Description |
|---|---|
| enableOngoingMonitoring | Boolean to enable on going monitoring (ongoing screening) of the case against the AML dataset |
ExternalReference parameter
The request includes an optional parameter called ExternalReference. This can be used to store your own internal identifier or reference number against the check.
If included, this value will act as an idempotency key. If a check exists against the same case with the same ExternalReference, the result from the previous run will be returned instead of a new check being performed.
Example
json
// Workflow request example with AML options
{
"caseId":"123",
"workFlowName":"aml",
"workflowOptions":{
"enableOngoingMonitoring":"true"
},
"externalReference":"123456789"
}AML workflow execution response
See below for example responses for the AML workflow - check the Swagger definition for the full schema: https://api-sandbox.eyedp.com/swagger
This example shows an individual match found with a PEP, Sanction, Enforcement and Adverse Media entry:
json
// RESPONSE from /api/workflows/execute (200)
{
"checkId": 2006,
"amlResponse": {
"matches": [
{
"riskId": 3228,
"riskRating": "High",
"isOverridden": false,
"entityId": "WX0012050221",
"type": "Individual",
"name": "Maria Elena Santos",
"status": "Alive",
"datesOfBirth": [
"1965-03-15"
],
"placesOfBirth": [
"Place 1",
"Place 2"
],
"nationalities": [
"Natioinality 1",
"Natioinality 2",
],
"citizenships": [
"Citizenship 1",
"Citizenship 2"
],
"relationships": [
{
"group": "Associations",
"type": "Friend",
"entityId": 1253678,
"dateModified": "2001-01-01T01:01:01+00:00",
"entityName": "Name of associate",
"ownershipPercentage": 0.0,
"segments": "Enforcement,PEP,Sanction"
},
{
"group": "Family",
"type": "Ex-Wife",
"entityId": 23456789,
"dateModified": "2001-01-01T01:01:01+00:00",
"entityName": "Family name",
"ownershipPercentage": 0.0,
"segments": "PEP,Sanction"
},
{
"group": "Companies",
"type": "Affiliated Company",
"entityId": 34567890,
"dateModified": "2001-01-01T01:01:01+00:00",
"entityName": "Company name",
"ownershipPercentage": 0.0,
"segments": "Sanction"
},
],
"addresses": [
{
"value": "BR",
"type": "Current"
}
],
"watchlistEntries": [
{
"key": 1,
"type": "Pep",
"source": "Government Records",
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"Executive Branch",
"Finance"
]
},
{
"key": 2,
"type": "Sanctions",
"source": "Market authority",
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"Sanction List"
]
},
{
"key": 3,
"type": "AdverseMedia",
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"Money Laundering"
]
},
{
"key": 4,
"type": "Enforcements",
"source": "Country or origin",
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"War Crimes"
]
},
],
"watchlistEntriesInfo": {
"sanctions": [
{
"key": 5,
"source": "Ministry of country XYZ",
"dateModified": "2022-03-01T01:44:03+00:00",
"subCategories": [
"Sanction List"
],
"country": "Country"
}
],
"peps": [
{
"key": 6,
"source": "Government Records",
"dateModified": "2023-06-15T10:30:00+00:00",
"subCategories": [
"Executive Branch",
"Finance"
],
"country": "BR",
"status": "Inactive",
"isPrimary": true,
"governingInstitution": "Ministry of Finance",
"governingRole": "Minister",
"effectiveDate": "2010-01-15",
"effectiveDateType": "Appointed",
"expirationDate": "2014-12-31",
"expirationDateType": "Official"
}
],
"adverseMedias": [
{
"key": 7,
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"Money Laundering"
],
"description": "Incident"
}
],
"sourceItems": [
{
"key": 8,
"sourceURI": "https:// example",
"dateModified": "2022-01-01T01:01:01+00:00"
}
],
"enforcements": [
{
"key": 9,
"country": "International",
"source": "International Criminal Court",
"subCategories": [
"War Crimes"
],
"dateModified": "2001-01-01T01:01:01+00:00",
}
]
},
"comments": "comment text will be here",
"matchConfidenceScore": 100,
"aliases": [
{
"category": "None",
"type": "AKA",
"scriptType": "Basic Latin",
"firstName": "abc",
"lastName": "abc",
"middleName": "abc",
"fullName": "abc"
},
],
"gender": "Female"
}
]
}
}And here is one for an business match found with a Sanction, Enforcement and SOE entry:
json
// RESPONSE from /api/workflows/execute (200)
{
"checkId": 8083,
"amlResponse": {
"matches": [
{
"riskId": 22585,
"riskRating": "High",
"isOverridden": true,
"entityId": "WX0005513308",
"type": "Business",
"name": "Company Name",
"status": "NotApplicable",
"datesOfBirth": [],
"placesOfBirth": [],
"nationalities": [],
"citizenships": [],
"relationships": [
{
"group": "Companies",
"type": "Affiliated Company",
"entityId": 9191930,
"dateModified": "2018-07-06T01:41:09+00:00",
"entityName": "Company Name",
"ownershipPercentage": 0.0,
"segments": "Other,SOE"
}
],
"addresses": [
{
"city": "City Name",
"country": "Country Name",
"category": "Associated",
"type": "Unknown"
},
{
"city": "City Name",
"country": "Country Name",
"postalCode": "Postal Code",
"category": "Business",
"type": "Unknown"
}
],
"watchlistEntries": [
{
"key": 1,
"type": "Sanctions",
"source": "Source Name",
"dateModified": "2022-02-25T01:48:27+00:00",
"subCategories": [
"Sanction List"
]
},
{
"key": 236,
"type": "Enforcements",
"source": "Source Name",
"dateModified": "2017-08-28T09:10:35+00:00",
"subCategories": [
"Excluded Party"
]
}
],
"watchlistEntriesInfo": {
"sanctions": [
{
"key": 1,
"source": "Source Name",
"dateModified": "2022-02-25T01:48:27+00:00",
"subCategories": [
"Sanction List"
],
"country": "Country Name"
}
],
"peps": [],
"adverseMedias": [],
"sourceItems": [
{
"key": 8,
"sourceURI": "Source URL",
"dateModified": "2022-03-07T03:27:37+00:00"
}
],
"enforcements": [
{
"key": 236,
"country": "Country Name",
"source": "Source Name",
"subCategories": [
"Excluded Party"
],
"dateModified": "2017-08-28T09:10:35+00:00"
}
]
},
"comments": "AML check comments",
"matchConfidenceScore": 100,
"aliases": [
{
"category": "None",
"type": "AKA",
"scriptType": "Basic Latin",
"lastName": "Company Name",
"fullName": "Company Name"
}
],
"soes": [
{
"isActive": true,
"countryAssociations": [
{
"type": "Ownership",
"country": "Country 1",
"ownershipPercentage": 50.23
},
{
"type": "Ownership",
"country": "Country 2",
"ownershipPercentage": 0.86
}
],
"dateModified": "2017-07-03T07:39:35+00:00"
}
]
},
]
}
}Sandbox environment
When integrating with the sandbox environment, the following cases will produce the following results:
| Name | DOB | Country | Result Type |
|---|---|---|---|
| Maria Elena Santos | 1965-03-15 | BR | Single PEP |
| Viktor Mikhailovich Petrov | 1972-08-22 | RU | Single Sanctions |
| John Michael Patterson | 1980-11-05 | GB | Single Adverse Media |
| Ahmed Hassan Al-Masri | 1968-05-30 | EG | 2 PEPs + 1 Sanctions |
| Carlos Eduardo Mendez | 1975-02-14 | VE | 1 Sanctions + 3 Adverse Media |
| Li Wei Zhang | 1963-07-18 | CN | 2 Sanctions |
| Nikolai Ivanov | 1970-04-12 | BY | 2 separate matches • 1 PEP • 1 Sanctions |
| Isabella Rodriguez | 1978-09-25 | MX | 2 separate matches • 1 Adverse Media • 2 PEPs + 1 Sanctions |
| Omar Al-Rahman | 1969-12-03 | SY | 2 separate matches • 1 Sanctions + 3 Adverse Media • 2 Sanctions |
Create cases that contain these names (the names can be partial) and DOBs and perform the workflow execution.
Check: Anomaly Detection
Anomaly detection looks for discrepancies in the document's content that could indicate that it's been modified.
This check is triggered as soon as a document is uploaded to EyeDP.
Examples of discrepancies
- Duplicate transactions within a bank statement.
- Unusually long expiration dates on passports or driving licences.
- Bill amounts that don't add up on utility bills.
- Obviously fake account numbers like '123456789'
All of these would be found and highlighted by this check.
Response
The anomaly detection response contains a list of all checks completed on the document content.
- Every check has a name and category to classify the check.
- The result can be one of two values: 'Pass' or 'Fail'
- A description is added only when the check fails. This gives information on why it has failed.
json
{
"id": 123,
"checkName": "anomaly-detection",
"checkLabel": "Anomaly detection",
"checkDescription": "Checks for anomalies within the documents content",
"createTs": "2026-05-14T09:13:19.463",
"anomalyDetectionResponse": {
"checks": [
{
"name": "person_name",
"version": "1.0",
"category": "Placeholder_data",
"result": "Pass"
},
{
"name": "bill_number",
"version": "1.0",
"category": "Placeholder_data",
"result": "Fail",
"description": "Potential sample or dummy bill number detected: '00000000/0'."
},
{
"name": "provider_vat_reg_number",
"version": "1.0",
"category": "Placeholder_data",
"result": "Fail",
"description": "Potential sample or dummy provider VAT reg number detected: '000 0000 00'."
},
{
"name": "bill_date_after_period_end_date",
"version": "1.0",
"category": "Date_coverage",
"result": "Pass"
},
{
"name": "due_date_after_period_end_date",
"version": "1.0",
"category": "Date_coverage",
"result": "Pass"
},
{
"name": "period_end_after_period_start",
"version": "1.0",
"category": "Date_coverage",
"result": "Pass"
},
{
"name": "period_length_less_than_one_year",
"version": "1.0",
"category": "Date_coverage",
"result": "Pass"
},
{
"name": "total_amount_consistent_with_charges_and_usage",
"version": "1.0",
"category": "Internal_consistency",
"result": "Pass"
},
{
"name": "Required fields present",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Billing and due dates logical",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Billing period within bill date",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Monetary reconciliation (charges, VAT, total, amount due)",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Account/reference consistency between bill and payment slip",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Invoice / VAT / Bill number plausibility",
"version": "1.0",
"category": "AI",
"result": "Fail",
"description": "Several identifier fields appear to be placeholder or all zeros rather than plausible values: 'Bill number: 00000000/0', 'VAT registration number 000 0000 00'. These look like non-unique placeholders and are unexpected on a VAT invoice."
},
{
"name": "Supply identifier / meter reference presence",
"version": "1.0",
"category": "AI",
"result": "Fail",
"description": "Typical business electricity bills include a supply identifier (MPAN/MPRN) or meter number. No meter number, MPAN, or MPRN is present in the extracted content. The bill does mention 'based on ESTIMATED readings' but does not provide an explicit meter or supply ID to tie consumption to a supply."
},
{
"name": "Contact/phone number plausibility",
"version": "1.0",
"category": "AI",
"result": "Fail",
"description": "A contact phone number is extracted as '0000 000 0000' (and elsewhere '0330 100 005' also appears). The '0000 000 0000' string is almost certainly a placeholder and not a valid customer contact number; presence of both a realistic number and a zero-placeholder increases inconsistency."
}
]
}
}