DocPipe Verify

Check an invoice before your agent or automation posts or pays it.

Send the invoice fields you already have, from any extractor. You get back a verdict, two flags your agent can act on, and the reason for every hold.

Quick start

1. Open DocPipe Verify on Apify and select Try for free.
2. In the Input tab, choose JSON and paste the example below. Set options.asOf when you need repeatable date checks.
3. Click Start. In the run's Storage → Dataset, inspect verdict, canAutoPost, canAutoPay, holdReasons, checks, and issues.
4. Supply priorInvoices to run the duplicate check before enabling payment. The Actor returns a decision; it never posts or pays an invoice.

A minimal passing invoice with duplicate history:

{
  "invoices": [{
    "vendor": "Northwind Supply Co.",
    "invoiceNumber": "NW-20841",
    "invoiceDate": "2026-10-08",
    "currency": "USD",
    "subtotal": 100,
    "tax": 8,
    "total": 108
  }],
  "options": {
    "asOf": "2026-10-09",
    "priorInvoices": [{
      "vendor": "Northwind Supply Co.",
      "invoiceNumber": "NW-20799",
      "invoiceDate": "2026-09-02",
      "currency": "USD",
      "total": 88
    }]
  }
}

For API usage, open the Actor's API tab for ready-to-run examples. Five synthetic fixtures are available in examples.

Run it from Node.js

This example calls the public Actor through Apify's official JavaScript client. It sends one synthetic invoice and prints the verdict and decision fields.

npm install apify-client
export APIFY_TOKEN="your-apify-api-token"
node examples/run-verify.mjs valid

Try the failing arithmetic case:

$node examples/run-verify.mjs mismatch

The first command should return PASS with both action flags true because duplicate history was supplied and checked. The second should return REJECT with TOTAL_MISMATCH. Use an Apify API token from your account settings; keep it in an environment variable and out of source control. Each run processes one invoice verdict, so applicable Actor event pricing and Apify platform usage apply. The sample uses synthetic invoice data only. For a complete AP workflow pattern, see the AP workflow integration tutorial.

Field	Meaning
verdict	PASS: every check that matters ran and passed. REVIEW: a warning, or not enough evidence (for example, totals that can't be reconciled). REJECT: a check failed, so don't post this data as given.
canAutoPost	true only when the verdict is PASS
canAutoPay	true only when the verdict is PASS and the duplicate check actually ran against priorInvoices and passed
holdReasons	Why either flag is false, for example TOTAL_MISMATCH, POSSIBLE_DUPLICATE, DUPLICATES_NOT_CHECKED, TOTALS_NOT_VERIFIED

A warning is never an approval, and a check that couldn't run is never reported as a pass.

The checks are deterministic: plain arithmetic and rules, with no AI deciding. The same request always gives the same answer, and inputHash identifies the request. It's computed from the parsed values, so key order, spacing, 561.6 vs 561.60 and Unicode spelling don't change it.

Checks

Check	What it does
requiredFields	Vendor, invoice number, invoice date and total are present
arithmetic	Subtotal + tax = total (to half a cent), with the expected and found amounts
lineItems	Line items add up to the subtotal (or the total when there is no subtotal)
dates	Not in the future; warns when over two years old, or due before issued
purchaseOrder	PO number present, when you set poRequired
duplicate	Compared with your priorInvoices on normalized values ("Northwind Supply Co." = "NORTHWIND SUPPLY, INC"; "INV-0041" = "inv 0041"). Same vendor and number: REJECT. Same vendor, currency and total within 7 days under a different number: REVIEW, with the matched invoice, since it may be a re-issue or a recurring charge.
approvedVendor	Vendor is on your approvedVendors list, when you send one
currency	A real ISO 4217 code, matching expectedCurrency if you set it; warns when currency is missing or the total is negative (credit note)
extractionConfidence	Fields your extractor scored below minFieldConfidence (default 0.8). Confidence is reported per field and never blended into a "safe" score.

Input rules

Amounts must be JSON numbers (not strings) with at most 4 decimal places. Dates must be YYYY-MM-DD. Unknown field names are rejected, so a typo like totl never silently becomes "missing total". Malformed invoices come back as verdict: "ERROR" with the field named, and aren't charged.

Example

Input:

{
  "invoices": [{
    "vendor": "Northwind Supply Co.", "invoiceNumber": "NW-20841", "invoiceDate": "2026-09-30",
    "currency": "USD", "subtotal": 520.00, "tax": 41.60, "total": 601.60
  }],
  "options": {
    "priorInvoices": [{ "vendor": "Northwind Supply Co.", "invoiceNumber": "NW-20799", "total": 388.10, "invoiceDate": "2026-09-02", "currency": "USD" }]
  }
}

Dataset item:

{
  "index": 0,
  "invoiceNumber": "NW-20841",
  "verdict": "REJECT",
  "canAutoPost": false,
  "canAutoPay": false,
  "holdReasons": ["TOTAL_MISMATCH"],
  "checks": { "requiredFields": "PASS", "arithmetic": "FAIL", "lineItems": "NOT_CHECKED", "dates": "PASS",
              "purchaseOrder": "NOT_CHECKED", "duplicate": "PASS", "approvedVendor": "NOT_CHECKED",
              "currency": "PASS", "extractionConfidence": "NOT_CHECKED" },
  "issues": [{ "code": "TOTAL_MISMATCH", "severity": "ERROR", "field": "total",
               "message": "Subtotal 520.00 + tax 41.60 = 561.60, but stated total is 601.60 (difference 40.00)",
               "reason": null, "expected": 561.60, "found": 601.60, "matchedInvoice": null }],
  "missingFields": [],
  "validatedFields": { "vendor": true, "invoiceNumber": true, "invoiceDate": true, "subtotal": false, "tax": false, "total": false },
  "fieldConfidence": {},
  "rulesetVersion": "2026-10.2",
  "inputHash": "sha256:..."
}

Example workflows

These five synthetic invoices demonstrate the main verification outcomes. Copy an input JSON file from the example fixtures into the Actor's Input tab to try a workflow.

Example	Scenario	Expected result
01-valid-with-history.json	Valid invoice; duplicate check runs against supplied history	PASS — auto-post and auto-pay allowed
02-total-mismatch.json	Invoice total does not equal subtotal plus tax	REJECT — TOTAL_MISMATCH; duplicate check passes
03-exact-duplicate.json	Vendor and invoice number match an invoice in supplied history	REJECT — DUPLICATE_INVOICE
04-missing-required-fields.json	Invoice date is missing and a required PO number is absent	REJECT — MISSING_DATE and MISSING_PO
05-valid-without-history.json	Valid invoice with no duplicate history supplied	PASS — auto-post allowed; auto-pay held with DUPLICATES_NOT_CHECKED

These outcomes were verified with synthetic test data using ruleset 2026-10.2. A verdict does not itself post or pay an invoice.

Integrate with n8n, Make, or an AI agent

DocPipe Verify accepts structured invoice fields, not PDF uploads. Extract fields in your existing workflow, run the DocPipe Verify Actor, then read the first Dataset item. Route REJECT and REVIEW to human review. Even when the verdict is PASS, only proceed with posting when canAutoPost === true; payment requires canAutoPay === true and your own authorization controls.

n8n: Use an HTTP Request node to call Apify's synchronous Actor endpoint POST https://api.apify.com/v2/acts/pycasdesign~docpipe-verify/run-sync-get-dataset-items with header Authorization: Bearer YOUR_APIFY_TOKEN and a JSON body containing invoices and options. Read the first returned item in an IF node. For posting, require verdict === "PASS" && canAutoPost === true; for payment, require verdict === "PASS" && canAutoPay === true and a separate approved payment step. Send every other result to a review queue. Keep the token in n8n credentials, not in workflow exports.

Make: Use an HTTP Make a request module with the same endpoint and JSON input, then a router. The pass route checks verdict, canAutoPost, and (if relevant) canAutoPay; the review route catches everything else. Store the Apify token as a secret connection, not in a public scenario.

AI agents: Invoke the Actor through Apify's MCP integration or Actor API, and treat the returned verdict, canAutoPost, canAutoPay, and holdReasons as machine-readable data. Do not let the agent infer permission to pay from a plain-language summary. Payment execution and approvals remain outside DocPipe Verify.

Start with the five synthetic example inputs before connecting real invoices. Verify the response format and Apify run-time limits in your environment.

Pricing

You're charged once for each invoice that gets a verdict. Malformed invoices aren't charged. When your run's spending limit is reached, the run stops; it never goes over. If the platform restarts a run, invoices already charged are delivered from saved results and aren't charged again.

Your data

Invoice fields are sent over HTTPS to the DocPipe API (Pycas Design Innovations, hosted on AWS) to be checked, and are not stored there. Invoice contents are never logged. Results are saved only in your own Apify storage. Send only the fields the checks need: no bank details are required.