Unified Accounting / ERP API

What Is a Unified Accounting / ERP API?

A unified accounting API is a single, standardized programming interface that lets your product read and write financial data — invoices, payments, expenses, journal entries, and purchase orders — across multiple accounting and ERP platforms without building a separate integration for each one.

Accounting and ERP platforms each have their own APIs with different authentication methods, object models, and rate limits. Knit normalizes these differences so your engineering team integrates once, and Knit handles the translation layer for every accounting system your customers use.

Knit normalizes four things across all providers:

How It Works

1. Your customer connects their accounting system
Knit's pre-built embedded auth UI handles OAuth, API keys, and token management per provider. Your team writes zero auth code.

2. Knit normalizes the data
Invoices, payments, expenses, and journal entries are all mapped to Knit's unified schema — regardless of how each accounting system stores or names them internally.

3. Your product calls one API
Use a single set of endpoints and data models across your entire product. Add a new accounting platform later? No code changes on your side.

4. Stay in sync with real-time webhooks
Native and virtual webhooks fire on record changes — a paid invoice, a new journal entry, an updated purchase order — with a consistent event schema across all providers.

Accounting Data Objects

The following objects are available through the unified schema. All fields are normalized across providers.

Accounts (Chart of Accounts)

The ledger accounts that make up a company's chart of accounts — assets, liabilities, equity, income, and expenses.

id, name, category, type, description, accountNumber, status,
currentBalance, companyId, currency, parentAccountId, createdAt, updatedAt

type Includes values like LIABILITY, ASSET, EQUITY, INCOME, EXPENSE. category distinguishes LEDGER_ACCOUNT from BANK_ACCOUNT.

→ Account data model · Create account · Update account · List accounts · Get account

Contacts (Customers & Vendors)

Customer and vendor records — a single Contact object with a contactType field distinguishing the two.

info: { id, name, contactType, status, accountNumber, companyId,
        currency, taxNumber, urls[], createdAt, updatedAt }
emails[]: { type, email }
phones[]: { type, phoneNumber }
addresses[]: { addressLine1, addressLine2, city, state, country, zipCode, addressType }

contactType is either CUSTOMER or VENDOR.

→ Contact data model · Create contact · Update contact · List contacts · Get contact

Invoices & Bills

Sales invoices and vendor bills — one object, distinguished by type (INVOICE or BILL) — with full line-item and payment detail.

info: { id, invoiceNumber, type, issueDate, dueDate, paidOnDate, totalAmount,
        remainingAmount, totalDiscount, totalTax, contactId, companyId,
        currency, exchangeRate, status, createdAt, updatedAt }
lineItems[]: { lineItemId, itemId, itemCode, itemName, description, taxRateId,
               accountId, taxAmount, totalAmount, quantity, unitRate,
               discountAmount, discountPercentage, trackingCategories[] }
addresses[]: { addressLine1, addressLine2, city, state, country, zipCode, addressType }
payments[]: { id, amount, referenceNumber, discount, mode, paymentLinkedTo, invoiceId, invoiceNumber }

→ Invoice data model · Create invoice · Update invoice · List invoices · Get invoice · Add invoice attachment

Payments

Payments applied against invoices or bills, including partial payments and payment method detail.

id, amount, referenceNumber, discount, mode, paymentLinkedTo,
invoiceId, invoiceNumber, createdAt, updatedAt

→ Payment data model · Create payment · Update payment · List payments · Get payment

Expenses

Employee or vendor expenses with line-item detail and account coding.

info: { id, transactionDate, employeeId, contactId, companyId, totalAmount,
        description, currency, exchangeRate, createdAt, updatedAt }
lineItems[]: { id, amount, accountId, description, contactId, taxRateId, trackingCategories[] }

→ Expense data model · Create expense · List expenses · Get expense · Add expense attachment

Journal Entries

Manual and system-generated journal entries with debit/credit line items.

info: { id, name, date, status, description, companyId, currency,
        exchangeRate, referenceNumber, createdAt, updatedAt }
lineItems[]: { id, accountId, companyId, amount, type, description }

lineItems[].type is DEBIT or CREDIT.

→ Journal entry data model · Create journal entry · List journal entries · Get journal entry

Purchase Orders

Purchase orders with vendor, delivery, and line-item detail.

info: { id, purchaseOrderNumber, status, issueDate, deliveryDate, totalAmount,
        totalTax, totalDiscount, customerContactId, vendorContactId,
        companyId, currency, exchangeRate, addresses[] }
lineItems[]: { lineItemId, itemId, itemCode, itemName, description, taxRateId,
               accountId, taxAmount, totalAmount, quantity, unitRate,
               discountAmount, discountPercentage, trackingCategories[] }

→ Purchase order data model · List purchase orders · Get purchase order

Vendor Credits & Credit Notes

Credits issued by a vendor (Vendor Credits) or issued to a customer (Credit Notes), including allocation against open invoices or bills.

id, contactId, amount, remainingAmount, status, currency, companyId, createdAt, updatedAt

→ List vendor credits · Create vendor credit · Update vendor credit · Get vendor credit by ID · Allocate vendor credit to a bill · Deallocate vendor credit · List credit notes · Create credit note · Update credit note · Get credit note by ID · Allocate credit note to an invoice · Deallocate credit note

Credit Card Transactions

Card transactions recorded against a connected account, with full CRUD support.

id, accountId, amount, date, description, status, companyId, createdAt, updatedAt

→ Create credit card transaction · Update credit card transaction · List credit card transactions · Get credit card transaction

Company & Employee

The Company object represents the legal entity or organization inside the connected accounting platform — most other objects (accounts, invoices, journal entries) carry a companyId referencing it. The Employee object represents a person inside the accounting system itself (distinct from Knit's HRIS Employee object), used where expenses or payroll journal entries need to link back to an individual.

Company:  id, name, currency, country, taxNumber, createdAt, updatedAt
Employee: id, name, employeeNumber, email, phone, status

→ Company data model · Get companies info · Employee data model · List employees · Get employee

Items, Tax Rates & Tracking Categories

Supporting reference objects used across invoices, bills, and purchase orders.

Items:               id, code, name, description
Tax Rates:            id, name, rate, type
Tracking Categories:  categoryId, categoryName, parentCategoryId, parentCategoryName

Tracking categories let you tag line items with cost centers, regions, or departments — normalized the same way whether the source is QuickBooks classes, Xero tracking categories, or NetSuite segments.

→ Items data model · Get items · Create item · Update item · Delete item · Get tax rates · Get tracking categories · List currencies

API Reference

All accounting endpoints are organized by category. Each endpoint works identically regardless of the underlying platform — pass your API key and the customer's X-Integration-Id, and the response schema is consistent across all providers.

Account APIs

Contact APIs

Invoice & Bill APIs

Payment APIs

Expense APIs

Journal Entry APIs

Purchase Order APIs

Vendor Credit & Credit Note APIs

Supported Platforms

Knit connects to 11 accounting and ERP platforms. A single integration gives you access to all of them.

Don't see a platform? Use the Connector Builder / Integration Agent to add it yourself in hours, not weeks.

Key Capabilities

Real-Time Sync & Webhooks

Knit supports both native webhooks (forwarded directly from platforms that emit them) and virtual webhooks (Knit polls the source, detects changes, and emits events). Both use the same subscription interface and event schema — your integration code is identical either way.

Supported event types include: record.new, record.modified, record.deleted, invoice.paid, and more.

Zero Data Storage

Knit never stores your customers' financial data at rest. Every API request passes through to the source accounting system in real time. This reduces your GDPR, CCPA, and SOC 2 compliance scope — there are no replicated invoices or journal entries sitting in a third-party system.

Multi-Currency & Multi-Company

Every core object — invoices, payments, journal entries, purchase orders — carries currency and exchangeRate fields, and most objects support linkedCompanyIds for organizations running multiple entities or subsidiaries through one connected accounting platform.

AI Connector Builder / Integration Agent

When a customer's accounting platform isn't in Knit's library, the AI Connector Builder lets your team define a new connector in hours. Specify the platform's API structure and data mapping; Knit's AI generates the connector.

Passthrough API

Need an object outside the unified APIs — a custom NetSuite saved search, a Xero-specific report? Passthrough lets you make direct calls to the underlying accounting system using Knit's authentication layer.

MCP Compatibility

Knit is MCP-compatible, giving AI agents authenticated read/write access to invoices, payments, expenses, and journal entries across every connected accounting system through the same unified layer — no per-provider auth or endpoint logic in your agent code.

Quick Start

Authentication

All requests require two headers:

Authorization: Bearer YOUR_API_KEY
X-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID

The X-Integration-Id is the unique identifier for a specific customer's connected accounting platform, issued after they complete the Knit auth flow.

Fetch invoices

curl --request GET \
     --url 'https://api.getknit.dev/v1.0/accounting.invoice.list?type=INVOICE' \
     --header 'accept: application/json' \
     --header 'Authorization: Bearer YOUR_API_KEY' \
     --header 'X-Knit-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID'

Response — same schema whether the customer uses QuickBooks, Xero, or NetSuite:

{
  "success": true,
  "data": {
    "invoices": [
      {
        "info": {
          "id": "0d93e033-6548-40ea-bdfd-e551b85f5d7e",
          "invoiceNumber": "INV-101",
          "type": "INVOICE",
          "issueDate": "2026-05-20T00:00:00Z",
          "dueDate": "2026-05-22T00:00:00Z",
          "totalAmount": 1100,
          "remainingAmount": 0,
          "totalTax": 100,
          "contactId": "65a3f750-de4c-463a-85b1-f04a3a37b45a",
          "companyId": "ac19c8f9-a901-4db3-bef1-5aaca2a7c15a",
          "status": "PAID"
        },
        "lineItems": [
          {
            "lineItemId": "3a9701e4-5f9b-4ee7-8474-daa6d5887d6e",
            "itemName": "Tshirt",
            "accountId": "4200",
            "quantity": 10,
            "unitRate": 120,
            "totalAmount": 1100
          }
        ],
        "payments": [
          {
            "id": "eeedd617-d2c4-4d8c-96f9-69eeeb62b1e6",
            "amount": 1100,
            "mode": "CASH",
            "invoiceId": "0d93e033-6548-40ea-bdfd-e551b85f5d7e"
          }
        ]
      }
    ],
    "nextPageToken": "1928hdhdhd&^"
  }
}

Create a journal entry

curl --request POST \
     --url https://api.getknit.dev/v1.0/accounting.journal.create \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'Authorization: Bearer YOUR_API_KEY' \
     --header 'X-Knit-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID'

Record a payment

curl --request POST \
     --url https://api.getknit.dev/v1.0/accounting.payment.create \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'Authorization: Bearer YOUR_API_KEY' \
     --header 'X-Knit-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID'

Use Cases

Automated Invoice-to-Cash

Sync invoices and payment status in real time to trigger dunning workflows, update customer-facing balance views, or reconcile revenue automatically.

Typical flow: invoice.paid webhook → update remaining balance → close dunning workflow → sync payment record back to source

Multi-Entity Financial Consolidation

Pull chart-of-accounts, journal entries, and invoices across every subsidiary's accounting system into one consolidated reporting layer.

Typical flow: fetch accounts + journal entries per linkedCompanyId → normalize currency via exchangeRate → aggregate into consolidated reporting

Embedded Bookkeeping & Spend Management

Power a bookkeeping or spend-management product that reads and writes expenses, bills, and journal entries directly into a customer's existing accounting system — no data migration required.

Typical flow: fetch chart of accounts → categorize incoming expense → write expense with correct accountId → attach receipt

Procure-to-Pay Automation

Read purchase orders and vendor bills, match them against receipts, and write approved payments back to the source system.

Typical flow: fetch purchase orders by status → match against incoming bill → create payment on approval → update purchase order status

Lending & Underwriting Data Access

Pull invoices, payments, and account balances from a business's connected accounting platform to power real-time credit and risk decisioning.

Typical flow: fetch accounts + invoices + payments → compute cash-flow and AR aging signals → feed underwriting model

AI Bookkeeping Agents

Feed normalized, real-time financial data into LLM pipelines and MCP-compatible AI agents to build bookkeeping copilots that categorize expenses and reconcile accounts autonomously.

Typical flow: sync accounts + expenses + invoices → embed into vector store → ground LLM categorization in live chart of accounts → use MCP write tools to post journal entries

FAQ

What is a unified accounting API?
A unified accounting API is a single, standardized interface that lets your product read and write financial data — invoices, payments, expenses, and journal entries — across multiple accounting and ERP platforms without building a separate integration for each one. You integrate with Knit once; Knit normalizes the data models, authentication, and API differences between providers.

What's the difference between a unified accounting API and a unified ERP API?
In practice the terms overlap heavily — accounting is the core financial layer inside most ERP systems. Knit's unified schema covers the accounting objects (accounts, contacts, invoices, payments, journal entries, purchase orders) that are common to both dedicated accounting platforms like QuickBooks and Xero, and the financial modules of larger ERP systems like NetSuite and Sage Intacct.

How long does it take to integrate?
Most teams go live in 1–3 days with Knit. Building a production-ready 1:1 native integration against a single platform like NetSuite typically takes several weeks — but when you build with Knit, one integration unlocks every connected accounting system, and Knit maintains all connectors as providers update their APIs.

Does Knit store financial data?
No. Knit is a pass-through layer — requests hit the source accounting system in real time and no data is stored at rest. This reduces your GDPR, CCPA, and SOC 2 compliance scope.

How does Knit handle multi-currency?
Every core object carries currency and exchangeRate fields, normalized the same way regardless of how the underlying platform represents currency conversion.

What if a customer's accounting platform isn't on the list?
Using the Connector Builder, we can add a new connector in hours.

Is Knit compatible with AI agents and MCP?
Yes. Knit is MCP-compatible, so agents in MCP-compatible frameworks can perform authenticated accounting read/write actions via Knit with no per-provider logic.

What's the passthrough API?
The passthrough API lets you make direct calls to the underlying accounting system using Knit's authentication layer. Use it for custom objects or fields outside the unified schema.

Next Steps