SQL Accounting (often discussed as SQL Account / SQL Financial) powers many Malaysian SME ledgers. Connecting it to ecommerce, POS, CRM, or a B2B portal is less about “calling an API” and more about respecting how SQL Account stores companies, documents, and stock.
This checklist is for developers and finance teams planning a real integration—not a demo CSV.
When you need delivery help, our SQL Account API Developer Malaysia page describes how we engage. Use this article to prepare the workshop before anyone writes code.
Before anything: align on outcomes
Finance and IT should answer in one sentence each:
- What must stop being manual? (e.g. “nightly sales import”, “stock Excel”, “debtor statements from three systems”)
- What must never be automated without approval? (e.g. GL journals, supplier payments)
If those answers conflict, pause. Integrations amplify unclear ownership.
1. Environment and access checklist
- SQL Account version and edition documented
- Company database location (on-prem server, private cloud, hosted)
- Non-production copy available for development (never build only against live)
- Least-privilege SQL or application user for the integration account
- Backup and restore tested so UAT mistakes are recoverable
- VPN / bastion / firewall rules agreed with IT
- PDPA: who can see buyer and invoice data in logs
Developers: treat the company DB as a product interface. Blind INSERT without understanding document tables is how you create audit nightmares.
2. Master data checklist
- Customer / debtor codes vs ecommerce guest checkout policy
- Item codes and UOM (piece vs carton) mapped explicitly
- Tax codes / SST settings match channel behaviour
- Chart of accounts owners named for clearing and fee accounts
- Multi-location / warehouse codes if stock is split
- Inactive items and blocked debtors handled (fail closed, not silent skip)
Finance tip: clean masters before go-live. Middleware cannot invent a correct TIN or tax code that does not exist in SQL Account.
3. Document-type checklist
List every document the integration may create or update:
| Document | Create? | Update? | Void/CN path? |
|---|---|---|---|
| Sales order / quotation | |||
| Invoice / cash sales | |||
| Credit note | |||
| Payment / receipt | |||
| Stock adjustment / transfer | |||
| Purchase / GRN (if in scope) |
For each yes:
- Required header fields
- Line fields
- Tax calculation ownership (source system vs SQL Account)
- Posting period rules (can we post into locked months?)
4. Sync direction and timing
- One-way vs two-way stock agreed
- Near-real-time vs batch (and why)
- Idempotency: same webhook must not double-post invoices
- Ordering: masters before transactions
- Timezone and business-day cut-off for Malaysia operations
5. Error handling checklist (non-negotiable)
- Dead-letter / failure queue with human-readable reason
- Alerts to finance and IT for sustained failure
- Replay procedure documented
- Partial success behaviour defined (header ok, lines failed → what?)
- Month-end freeze process (pause writers during closing if needed)
Silent failures are the #1 reason finance loses trust in “the API.”
6. Security and change control
- Credentials stored in a secrets manager, not chat history
- Deployments require approval; production writes have an audit trail
- Schema or mapping changes versioned with finance sign-off
- Support runbook: who picks up the phone at 11 p.m. before tax filing week?
7. UAT scenarios finance should insist on
Developers often test “happy path invoice.” Finance should demand:
- Standard B2B invoice with SST
- Cash sales / walk-in
- Partial payment and full payment
- Credit note against posted invoice
- Stock insufficient / negative stock policy
- Duplicate order ID replay
- Customer missing from SQL Account
- Item UOM mismatch
- Locked posting period
- High-volume day simulation (at least a few hundred docs if that is your reality)
Sign UAT with named finance and ops owners—not only the project manager.
8. Path to MyInvois (if mandated)
If SQL Account documents are (or will be) the legal invoice source:
- Buyer TIN/BRN quality checked
- Document types in scope for e-invoice listed
- Decision: portal vs middleware (see our portal vs API article and e-invoicing service)
- Rejection workflow owned by finance
Do not run MyInvois from the storefront while SQL Account remains a delayed copy.
9. Commercial / vendor checklist
When hiring a SQL Account API developer Malaysia partner:
- They ask about document types and tax codes before quoting a fixed price
- Sample company UAT is in the SOW
- Source code / mapping docs handover is explicit
- Hypercare around first month-end is priced
- MYR quote lists exclusions (licences, data cleansing, third-party API fees)
Suggested project phases
- Discovery workshop (this checklist filled)
- Masters sync
- Sales documents
- Payments / stock (as needed)
- Stabilisation + optional e-invoice bridge
Bottom line
Successful SQL Accounting integration is a shared checklist between developers and finance—not a weekend script. Prepare access, masters, document types, and failure handling before coding; hire partners who speak both SQL Account and operational Malaysian finance.
Ready to scope a bridge? Book a consultation or read the SQL Account API Developer Malaysia service overview.