Building a document intelligence engine in FileMaker

The goal: stop keying documents by hand

Every business that handles documents has someone retyping them into a system. It's slow, error-prone, and exactly the kind of work an AI model is good at. The design goal here is an engine that's document-type agnostic: it ships with invoices and POs, but adding "receipts" or "contracts" later should mean adding a configuration record and one small script — not touching the core. And it runs natively in FileMaker, no plugins.

The architecture

Four ideas keep this clean and cheap to extend:

• Extract text in FileMaker, not in the AI call. A Web Viewer runs PDF.js (Mozilla's open-source PDF library) to pull the text layer out of the PDF, then fires it back to FileMaker. You send the model text, not a binary PDF — far fewer tokens, far lower cost.
• The AI provider is a database record. Endpoint, auth header format, request template, and the JSON path to the reply all live in a Provider table. Switching from one model vendor to another is a field change.
• Document types are data. Each type's system prompt, JSON schema, and parser-script name live in a DocType table. The engine never hardcodes "invoice."
• Scanned PDFs fall back to vision. If PDF.js finds no real text layer, the engine routes the original PDF to the model's document/vision path instead.

The data model

Globals      system settings: active provider, API key, the Web Viewer HTML template
Provider     one row per AI vendor: endpoint, auth format, request template, response path
DocType      one row per document type: system prompt, JSON schema, parser script name
Document     one row per processed file: the PDF, extracted text, raw response, status
LineItem     child rows for invoice/PO line items
*_Result     parsed fields per type (Invoice_Result, PO_Result, …)

A Provider row is just configuration. Two examples, side by side, show why this scales — the engine reads Response_Path to find the reply regardless of vendor:

Provider A   endpoint: https://api.anthropic.com/v1/messages
             auth:     x-api-key: %%KEY%%
             response: content[0].text

Provider B   endpoint: https://api.openai.com/v1/chat/completions
             auth:     Authorization: Bearer %%KEY%%
             response: choices[0].message.content

End to end

1. User attaches a PDF and picks a document type.
2. A script base64-encodes the PDF and injects it into the Web Viewer's HTML template (in place of a %%BASE64PDF%% placeholder).
3. PDF.js extracts the text page by page and calls FileMaker.PerformScript("ReceiveText", extractedText).
4. If fewer than ~20 meaningful characters come back, it's a scanned PDF — route to the vision fallback instead.
5. The AI script builds the request body from the Provider + DocType records and posts it with Insert from URL.
6. The reply text is pulled out using the provider's Response_Path, then the router calls the parser named in DocType::Parser_Script_Name.
7. That parser uses JSONGetElement to map JSON keys into result fields, writing line items to the child table.

Adding a new document type

This is the payoff. To support a new type, you never edit the engine:

1. Add a DocType record: name, system prompt, and JSON schema.
2. Create a result table whose fields match the schema keys; relate it to Document.
3. Write one parser script (e.g. Parse_Receipt) that maps JSON keys to fields with JSONGetElement.
4. Put that script's name in DocType::Parser_Script_Name. Done — the router picks it up.

When this fits

This pattern earns its keep when documents flow in continuously and the field layout is predictable per type — accounts payable, order intake, onboarding paperwork. For a one-time pile of documents, a manual tool may be cheaper. But if people are retyping the same shapes of paper every week, an engine like this pays for itself fast and keeps your data clean.