MISA Accounting API Integration: An Implementation Guide

First confirm which MISA product you need to integrate

MISA API integration is a broad request, but the technical scope only becomes clear after identifying the product. AMIS Accounting is for a company's accounting data; MISA ASP serves accounting-service workflows; MISA meInvoice has separate APIs for electronic invoices. One product's documentation should not be used to assume that every MISA edition exposes the same endpoints or transactions.

MISA's official integration portal describes a registration process in which the developer and MISA clarify the required business workflows, agree on scope, and then receive API documentation, an implementation environment and technical standards. The AMIS Accounting overview likewise requires registration for an app_id and callback URL before obtaining an access_code and access_token.

A credible estimate therefore starts with the product, version, accounting tenant, requested transactions and API permission confirmed by MISA. Friday Works is not MISA, and this article does not claim certified integration-partner status; an implementation must use MISA's official registration channel and approved scope.

• ✓AMIS Accounting: master-data synchronization and accounting voucher requests for a business.
• ✓MISA ASP: a separate flow for accounting-service providers and multi-client data.
• ✓MISA meInvoice: inbound or outbound e-invoice flows, not the entire accounting workflow.

An accounting integration is complete when orders, master data and vouchers reconcile end to end—not when the API merely accepts a request.

What belongs in a website or sales-system → MISA flow?

Inputs commonly include orders, payments, refunds, customers, products and warehouses from a website, web app, POS or ERP. The output should not be a raw copy of the source payload. The integration translates business events into approved master data, voucher requests and reconciliation states.

MISA's AMIS Accounting documentation lists read or create operations for customers and other entities, materials, warehouses, units, charts of accounts, organizational structures and bank accounts. Documented voucher areas include sales, purchases, invoices, stock receipts and returns. The user guide updated on 3 August 2026 states that connected data can create vouchers in Cash, Bank, Purchasing and Sales modules.

A clean architecture has three layers: the source owns order state, a connector normalizes and delivers events, and MISA receives them and creates vouchers under configured rules. Avoid placing API credentials in the browser or relying on a plugin with no durable log or recovery path.

• ✓Source events: order_confirmed, payment_captured, refund_completed or return_received.
• ✓Foundation data: customer, item, warehouse, unit, branch and accounting account.
• ✓Outcome: voucher request, final state, voucher reference or an actionable error.

Synchronize master data before vouchers

The most common failures are mapping failures rather than HTTP failures. A website SKU may not exist in AMIS, a warehouse name may refer to another branch, or identical display units may use different internal codes. Sending a voucher before its master data is ready can reject the request or post it to the wrong entity.

Create a data contract for every field: source, data type, external ID, corresponding MISA ID, creation rule, approver and missing-value behavior. MISA's documentation uses branch_id to identify the organizational unit and org_company_code to distinguish the connecting software or customer. Treat these as versioned configuration rather than scattered constants.

Every master-data type needs a two-way mapping table and sync state. If accounting changes a warehouse code, merges a customer or disables an item, the connector should detect the change instead of silently creating another record.

• ✓Stable source keys: customer_id, sku, warehouse_id, order_id and payment_id.
• ✓Target keys: MISA customer, item, warehouse, unit, branch_id and account codes.
• ✓Exception policy: create, await accounting approval, use a controlled default or reject.

An accepted request is not a completed voucher

The official AMIS Accounting Open API documentation explicitly describes voucher creation as asynchronous: the system can accept a request even when the accounting data has not yet succeeded; the business result is final only after the voucher is created. An order must not be marked posted as soon as an endpoint returns Success=true.

Store an integration job with a stable external reference, request ID, submission time, attempt count, acceptance state, callback state and final voucher reference. The callback must identify the job; duplicate or delayed callbacks must remain idempotent.

If MISA is temporarily unavailable, the source event remains durable and retries under policy. If data is invalid, move the job to needs_attention with an actionable error so accounting or operations can repair the mapping and replay it without inventing another order.

• ✓accepted: MISA received the request, not the final accounting result.
• ✓processing: the voucher is being created or validated.
• ✓completed/failed: the state used for reconciliation and human intervention.

Reconcile amounts, tax, discounts and returns

Commerce orders can contain tax-inclusive or tax-exclusive prices, line or order discounts, shipping, payment fees, loyalty points and split payments. Comparing only the grand total can hide incorrect revenue, tax or receivable structure.

Accounting and the process owner must approve the business mapping before development: recognition point, debit and credit accounts, tax code, rounding, currency, branch, warehouse and return behavior. Engineers should not infer accounting entries from website field labels.

A reconciliation report compares eligible source orders, accepted jobs, completed vouchers, merchandise, tax, discount, fees, refunds and variance by date and external reference. A zero aggregate variance is not enough; the team must drill down to order and line level.

• ✓A golden dataset covers normal orders, discounts, multiple tax rates, shipping, partial refunds and full returns.
• ✓The source, connector and MISA use the same rounding policy.
• ✓Accounting signs off the result; acceptance is not delegated solely to engineering.

Operate authentication, tokens and callbacks safely

According to MISA's documentation, AMIS Accounting uses a registered app_id, an access_code obtained from the application and an access_token valid for 12 hours; business requests carry X-MISA-AccessToken. Tokens belong in a server-side secret store, rotate before expiry and must not appear in logs, URLs or frontend code.

A callback is a public endpoint, so constrain the method, payload size, content type and schema; record its request ID before processing; prevent replay with an idempotency key; and redact sensitive data from logs. Return success only after the callback event has been stored durably.

Monitor the age of unfinished jobs, failure rates by ErrorCode, token-refresh failures and reconciliation variance. Alerts need an accountable owner; a dashboard without a replay runbook is not an operational handover.

• ✓Never store access_code or access_token in a browser, Git repository or documentation screenshot.
• ✓Separate test and production configuration; do not use real data in test without authorization.
• ✓Keep an audit trail for mapping changes, job replays and manual overrides.

Quotation and acceptance checklist

Before requesting a quote, provide the MISA product, API registration state, source system, branch count, daily order volume, master data, voucher types, accounting rules and latency requirement. A reliable provider should not price “connect our website to MISA” as a fixed package without this discovery.

A pilot should use an account or test environment provided by MISA, an accounting-approved golden dataset and the full path from source event to final voucher. MISA documents official registration, implementation or sandbox access and technical support; the available environment must be confirmed for the exact product and account.

Friday Works can assess feasibility and design the data contract, connector, callback, reconciliation dashboard and runbook within the official API scope. The discovery outcome should state what MISA supports, what requires a process change and what should remain manual.

• ✓Every test traces order_id through an integration job to the final voucher reference.
• ✓Retries and duplicate callbacks do not create duplicate master data or vouchers.
• ✓Amount, tax, discount, fees and refunds reconcile per order; every failure has an owner and SLA.