Accounts payable API
Accounts Payable API: Invoice Processing API and Invoice OCR API for Developers
Post a PDF or an image to one endpoint and get back a structured bill: vendor, invoice number, dates, currency, subtotal, tax, total and line items, as JSON. The AutoPayables accounts payable API is a plain REST API with bearer-token auth, so you can wire AI invoice capture into your own product, your ERP, or an internal AP workflow without building an extraction engine. Drop an invoice into the tool above to see exactly what the API returns before you write a line of code.
Try it now, capture a real invoice
Free plan, no credit card, your data stays yours
1 endpoint
POST /api/invoices/upload is all you need to get structured invoice data back
JSON
Vendor, invoice number, dates, currency, subtotal, tax, total and line items
No templates
The model reads invoice layouts it has never seen, so you skip per-vendor mapping
$149/mo
API access is included on the Scale plan, with unlimited invoices
Syncs to your accounting system
What the accounts payable API gives you
A REST interface over the same AI capture and approval engine the web app runs on, so what you see in the tool above is what your code receives.
Invoice OCR that returns fields, not text
Traditional OCR hands you a wall of characters and leaves you to guess which number is the total. This API returns typed fields: vendor, invoice_number, invoice_date, due_date, currency, subtotal, tax, total, and an array of line items with description, quantity, unit price and amount.
Plain REST with bearer auth
Authorization: Bearer YOUR_API_TOKEN, Accept: application/json. No SDK to install, no SOAP, no XML envelope. A single curl command with a multipart file upload is a working integration.
PDF and image in, structured bill out
Send a native PDF, a scan, or a phone photo. The upload endpoint stores the file, runs extraction, and returns the created bill in the same response, including a hash you can use to fetch it again later.
Read back bills and vendors
GET /api/invoices lists bills, GET /api/invoices/{hash} retrieves one, and GET /api/vendors returns your vendor records. Enough to sync state into your own system on a schedule or after a webhook.
The approval layer comes with it
Invoices land as drafts. You can leave a human to review and approve in the AutoPayables UI, or drive the whole thing from your side and use the API purely as an extraction service. Both patterns are supported.
Accounting sync you do not have to build
Approved bills push into QuickBooks Online, Xero, NetSuite and Sage Intacct through our existing integrations. If your product serves accountants, you inherit those connections instead of writing four of them.
How it works
Create an API token
API access is included on the Scale plan. Generate a bearer token from your account's API tokens page.
POST the invoice
Send the file as multipart form data to /api/invoices/upload with your bearer token in the Authorization header.
Read the structured bill
The response contains the bill object with vendor, totals, dates and line items, plus a hash to retrieve it later.
Do whatever you need with it
Write it into your ERP, show it in your own UI, or let it flow through AutoPayables approvals and into the accounting system.
Manual vs automated
Building invoice extraction yourself
- Train or tune a model, then maintain it
- Per-vendor templates that break when a layout changes
- Write your own QuickBooks, Xero and NetSuite connectors
- Build an approval UI before anyone can use it
- Months of engineering before the first invoice is read
Calling the accounts payable API
- One POST request, structured JSON back
- Layout-independent extraction, no template to maintain
- Accounting sync already built and maintained
- Approval routing and audit trail included
- A working integration in an afternoon
Who it is for
Vertical SaaS adding AP to its product
Your customers already run their business in your software and email you their vendor bills. Call the API on each attachment and give them coded, approved bills without becoming an accounting company.
Accounting and bookkeeping firms
Push client invoices through the API from your intake pipeline and land them in each client's books already coded. See our page on AP automation for accounting firms.
ERPs without good capture
If your ERP has solid AP but weak inbox capture, use the API as the front door and post clean data in. This is the pattern behind our Odoo, Epicor and Sage 100 pages.
Internal finance engineering
A finance team with a developer can drop invoice data entry entirely: watch the AP mailbox, POST each attachment, and write the JSON into your data warehouse or ERP staging table.
What is an accounts payable API?
An accounts payable API is an interface that lets your own code do the work an AP clerk would otherwise do by hand: submit a vendor invoice, get back structured data, and move the bill through approval and into the accounting system. The AutoPayables API is a REST interface over our AI capture engine. You send a file, and you receive a bill object with the fields already typed and separated, rather than a blob of OCR text you have to parse.
That distinction is the whole point. Character-level OCR has been available for decades and it is not what makes AP hard. The hard part is knowing which of the fourteen numbers on the page is the invoice total, which date is the due date rather than the ship date, and how the line items break down. That is a document-understanding problem, and it is what the API solves.
What the invoice processing API returns
A successful upload returns the created bill. The shape is stable and boring on purpose, so it maps cleanly into whatever schema you already keep.
| Field | Type | What it holds |
|---|---|---|
| hash | string | Stable identifier used to retrieve the bill later |
| status | string | Where the bill is in the workflow, starting as a draft for review |
| vendor | string | The supplier name as read from the document |
| invoice_number | string | The vendor's own reference, used for duplicate detection |
| invoice_date, due_date | date | Issue date and payment due date, normalized |
| currency | string | Currency code on the document |
| subtotal, tax, total | number | The money fields, kept separate so you can check that they reconcile |
| line_items | array | Each line with description, quantity, unit_price and amount |
Line items are the field most invoice OCR APIs handle badly, and they are the field that decides whether you can do anything useful downstream. Without them you cannot code an invoice to more than one GL account, you cannot run a three-way match against a purchase order, and you cannot spot a price variance. With them you can do all three.
How do I integrate an invoice OCR API?
Three calls cover almost every integration. Authenticate with a bearer token, POST the file as multipart form data, and read the bill from the response. There is no queue to poll for a simple invoice and no callback to configure before you get your first result, which means a proof of concept is a single curl command.
A realistic production flow adds one more step: reconcile. Run GET /api/invoices on a schedule to pull the current status of bills you have submitted, so your system knows which ones have been approved and which are still sitting in review. If your team approves inside AutoPayables and your system is the reader, that one polling job is your entire sync.
Invoice OCR API vs building your own extraction
Teams that decide to build usually underestimate the same three things. First, the long tail: a model that reads the ten vendors you tested on is not a model that reads the four hundred vendors your customers use. Second, maintenance: templates break the moment a supplier redesigns its invoice, and someone owns that forever. Third, everything around extraction, which is where the real time goes. Duplicate detection, approval routing, an audit trail, and connectors to four accounting systems are all unglamorous and all mandatory, and none of them are extraction.
Buying the extraction and the workflow together means your engineers work on the part of the product only you can build. If you would rather hand the whole AP process to a finance team instead of building anything, our accounts payable software does the same job through a UI.
Does the accounts payable API handle approvals and payments?
Approvals, yes. Invoices arriving through the API land as drafts and can flow through the same approval rules, reminders and audit trail as invoices that arrive by email, so a bill created by your code is indistinguishable from one a person uploaded. That matters for auditors, who care that every payment has an approval attached, not that a robot created the record.
Payments are where honesty is worth more than a feature checkbox. AutoPayables approves and codes bills and pushes them into your accounting system, which is where the payment run happens, through ACH or a bank file. We are not a payment network, so if what you need is an API that moves money across borders and collects tax forms, look at a payout platform. Our B2B payments platform page explains where that line sits.
What does the API cost?
API access is included on the Scale plan at $149 a month, which carries unlimited invoices. There is no per-call charge, which is unusual in this category: most invoice OCR APIs bill per page or per document, so a high-volume month produces a surprise. A flat plan means you can build a product on top of it without your unit economics moving under you. You can still start on the free plan to test capture accuracy in the UI before you upgrade for a token. Full tiers are on the pricing page.
Getting started
Upload one real invoice at the top of this page and look at what comes back. That is the same extraction the API performs and the same fields it returns. If the vendor, the totals and the line items are right on a document you would call difficult, the rest is a curl command and an afternoon. When you are ready for the endpoint reference, the API documentation has the request and response examples in full.
Frequently asked questions
An accounts payable API lets your code submit vendor invoices and receive structured data back, then move those bills through approval and into an accounting system. The AutoPayables API is REST with bearer-token auth: you POST a PDF or image to /api/invoices/upload and receive a bill object with vendor, invoice number, dates, currency, subtotal, tax, total and line items as JSON.
Create a bearer token, POST the invoice file as multipart form data to the upload endpoint, and read the returned bill object. That single call is a working integration. Production systems usually add a scheduled GET /api/invoices to pull approval status back, so their records stay in sync with what finance has signed off.
An invoice OCR API converts a document to text or fields and stops there. An accounts payable API also carries the process: duplicate checks, approval routing, an audit trail, and a sync into your accounting system. Extraction is roughly a quarter of the work in AP, so an API that only extracts leaves you to build the other three quarters.
Yes. Each bill includes a line_items array with description, quantity, unit price and amount per line. Line-level data is what makes multi-account GL coding, purchase order matching and price variance checks possible, and it is the field that most cheap OCR services either skip or return unreliably.
API access is included on the Scale plan at $149 a month with unlimited invoices, and there is no per-call or per-page fee. That is deliberate: most invoice OCR APIs bill per document, so a busy month costs more than a quiet one. A flat plan lets you build a product on top of the API without your margins moving.
Yes. Bills created through the API use the same accounting integrations as the rest of the platform, so an approved bill syncs into QuickBooks Online, Xero, NetSuite or Sage Intacct with its coding intact. If you are building on top of us, you inherit those connectors instead of writing and maintaining four of your own.
No. The extraction is layout-independent, so an invoice from a supplier the system has never seen is read the same way as a familiar one. This is the main practical difference from template-based OCR, where every new vendor layout means a mapping exercise and every vendor redesign means a broken template.
Test the extraction before you integrate
Run a real invoice through the tool on this page. The fields you see are the fields the API returns. If the accuracy holds on your ugliest vendor, the integration is the easy part.
Z tej samej rodziny narzędzi