Enjin Padanan Kesediaan Audit untuk Firma Akauntan

Apa dia: aplikasi web yang memberi firma akauntan satu nombor bagi setiap klien, setiap bulan — berapa peratus transaksi bank klien itu yang mempunyai resit atau e-Invois yang sepadan dalam rekod. Klien hanya perlu tangkap gambar resit setiap hari; OCR membaca jumlah, tarikh dan pembekal secara automatik serta mencadangkan kategori (pendapatan/perbelanjaan, cth. "Bekalan Pejabat") — tiada taip manual. Sistem kemudian memadankan data itu dengan penyata bank klien dan menyenaraikan dengan tepat apa yang masih tertinggal. Firma dapat melihat semua klien dalam satu jadual, disusun mengikut siapa yang paling ketinggalan, sebelum LHDN bertanya.

Siapa patut beli: rakan kongsi (partner) atau pengurus praktis di firma akauntan/pembukuan yang mempunyai cukup klien (sekurang-kurangnya 50, dibina untuk 200+) sehingga "mengejar resit" sudah menjadi kos operasi yang nyata — bukan pengamal solo dengan 5 klien yang boleh terus menelefon setiap seorang.

Masalah yang diselesaikan

• Di bawah undang-undang Malaysia, perniagaan wajib menyimpan rekod selama 7 tahun (Akta Cukai Pendapatan 1967 s.82; Akta Syarikat 2016 s.245). Rekod yang hilang semasa audit bermakna LHDN boleh membuat "penilaian anggaran terbaik" — klien dikenakan cukai berdasarkan anggaran pegawai cukai, bukan angka sebenar mereka. Penalti boleh mencecah RM10,000/12 bulan penjara (individu) atau RM500,000 (syarikat, termasuk pegawai yang bertanggungjawab).
• Pada masa ini, firma hanya tahu rekod klien tidak lengkap apabila sudah terlambat — semasa penutupan akhir tahun, atau lebih teruk, semasa audit sebenar sedang berjalan. Tiada amaran awal.
• Portal "sila muat naik dokumen anda" yang generik tidak menyelesaikan masalah ini: klien boleh memuat naik invois rawak yang tiada kaitan dengan apa yang berlaku dalam akaun bank mereka, tandakan tugasan sebagai "selesai," dan firma tiada cara untuk tahu muat naik itu sebenarnya tidak merangkumi transaksi yang berlaku.

Titik jualan utama

• Satu jadual boleh susun merentasi semua 200+ klien: % sepadan bulan ini, klien paling ketinggalan dahulu. Tiada lagi teka siapa yang ketinggalan.
• Senarai jurang adalah khusus — "8 transaksi pada tarikh-tarikh ini tiada resit" — bukan peringatan kabur "sila hantar dokumen anda."
• Dibina berdasarkan data kewangan sebenar (penyata bank), bukan pengesahan senarai semak yang dilaporkan sendiri, jadi nombor itu tidak boleh "dipermainkan" dengan memuat naik sesuatu yang tidak berkaitan.
• Tiada kemasukan data manual: OCR membaca jumlah, tarikh, dan pembekal setiap resit, serta mencadangkan kategori — klien hanya tangkap gambar, akauntan semak dan sahkan berbanding menaip semula dari awal.

Cadangan nilai teras, satu ayatTukar "adakah klien membalas permintaan kami" kepada "adakah dokumen klien ini sebenarnya cukup lengkap untuk bertahan semasa audit" — menggunakan transaksi bank mereka sendiri sebagai asas kebenaran, bukan senarai semak.

Ini bukan pasaran yang kosong. Dua kategori global yang matang dan bermodal kukuh sudah wujud dan bertindih sebahagian:

Apa maksudnya dari segi komersialJual idea ini sebagai "logik OCR-dan-padanan Dext, disesuaikan untuk Malaysia dan dibingkai sekitar risiko audit LHDN" — bukan sebagai kategori yang tiada siapa pernah fikirkan. Pengekstrakan OCR dan pengkategorian automatik (membaca jumlah/tarikh/pembekal daripada gambar resit, mencadangkan pendapatan/perbelanjaan dan kategori) kini adalah standard asas dalam kategori ini, bukan pembeza dengan sendirinya — itu asas yang klien jangkakan, bukan pitching utama. Kelebihan daya saing adalah nipis (Dext boleh menambah sokongan MyInvois bila-bila masa), jadi kelajuan mendapatkan hubungan sebenar dengan firma akauntan lebih penting daripada teknologi itu sendiri.

Terdapat dua perjalanan berasingan: firma akauntan (HQ), dan setiap klien SME HQ. Bahan pitching memerlukan kedua-duanya.

Perjalanan HQ

flowchart TD
  A["Rakan kongsi HQ dengar tentang produk
daripada pengasas komersial"] --> B["Demo: muat naik penyata bank
satu klien sebenar + folder resit"]
  B --> C{"Lihat senarai jurang
yang boleh dipercayai?"}
  C -- "tidak, data kelihatan salah" --> D["Pengasas laraskan peraturan padanan,
demo semula dengan sampel lebih bersih"]
  C -- "ya" --> E["HQ tandatangan perjanjian rintis
untuk 5-10 klien"]
  E --> F["HQ jemput klien tersebut
secara pukal melalui e-mel"]
  F --> G["HQ semak papan pemuka setiap minggu"]
  G --> H{"Jurang semakin
mengecil?"}
  H -- "tidak" --> I["HQ kejar klien secara terus,
produk ditandakan tidak cukup bersendirian"]
  H -- "ya" --> J["HQ kembangkan kepada senarai penuh klien"]
    

Perjalanan klien SME

flowchart TD
  A["Klien terima e-mel/WhatsApp jemputan
daripada firma akauntan mereka"] --> B["Klien buat akaun,
tiada pilihan — firma yang wajibkan"]
  B --> C["Tabiat harian: klien tangkap gambar
setiap resit/invois sebaik sahaja berlaku"]
  C --> D["OCR ekstrak jumlah, tarikh,
pembekal; cadangkan kategori"]
  D --> E["Sekali sebulan: klien muat naik
penyata bank (PDF/CSV)"]
  E --> F["Enjin padanan bandingkan resit
dengan transaksi bank"]
  F --> G["Sistem papar: X% sepadan,
ini senarai yang masih tertinggal"]
  G --> H{"Klien muat naik
yang tertinggal?"}
  H -- "ya" --> I["Peratusan naik,
senarai tertinggal mengecil"]
  H -- "tidak, bulan ini" --> J["Peringatan harian diteruskan
sehingga penutupan akhir bulan"]
    

Klien tidak memilih untuk membeli produk ini — firma akauntan yang mewajibkannya. Nada komunikasi semasa pendaftaran dan peringatan perlu mencerminkan "akauntan anda memerlukan ini," bukan pendaftaran SaaS biasa. Tabiat menangkap gambar resit setiap hari (bukan kelam-kabut sekali sebulan) ialah tabiat yang produk ini perlu bina — muat naik penyata bank adalah bukti bahawa tabiat itu benar-benar merangkumi semuanya.

Sengaja dikecualikan semasa pelancaran: pembukuan penuh, pemfailan cukai, atau penggantian perisian perakaunan. Produk ini melakukan satu tugas — beritahu firma siapa yang berisiko audit dan sebabnya — dan berhenti di situ.

Onboarding, langkah demi langkah: HQ mendaftar → HQ jemput kumpulan rintis klien secara pukal (mulakan dengan 5–10, bukan 200) → setiap klien terima e-mel, buat akaun, muat naik penyata bank dan resit satu bulan → HQ lihat papan pemuka pertama dalam masa beberapa hari, bukan minggu.

Andaian garis masa — bukan janjiP0 yang berfungsi (penguraian penyata bank + pengekstrakan resit OCR + padanan + papan pemuka HQ) secara realistik mengambil masa 9–11 minggu untuk pembangun solo, dengan andaian kepelbagaian format penyata bank dan ketepatan OCR pada resit Malaysia sebenar adalah risiko teknikal utama (lihat B.2). Ini mengandaikan tiada integrasi MyInvois semasa pelancaran — ia sengaja ditangguhkan. Jika firma rintis berkeras mahukan MyInvois dari hari pertama, tambah 4–6 minggu dan anggap ia sebagai rundingan berasingan, bukan sebahagian garis masa ini.

• Padanan tidak sempurna pada hari pertama — kes samar-samar (bayaran berpecah, perbezaan pembundaran, keterangan resit yang kabur) memerlukan langkah "sahkan padanan ini" secara manual oleh klien atau kakitangan firma. Ini normal untuk kategori ini, bukan pepijat.
• Tiada rujukan silang MyInvois semasa pelancaran. Bagi klien melebihi ambang e-Invois, % penyiapan hanya berasaskan resit sehingga ini diselesaikan (lihat soalan terbuka B.1).
• Ini tidak memfailkan cukai, menutup buku, atau menggantikan perisian perakaunan sedia ada firma — ia lapisan keterlihatan, bukan sistem pembukuan.
• Format penyata bank berbeza dengan ketara antara bank Malaysia; beberapa klien pertama yang didaftarkan akan mendedahkan kes tepi format yang perlu dibetulkan apabila ia timbul, bukan semuanya diselesaikan terlebih dahulu.

Gambaran keseluruhan produk

Aplikasi web dua peringkat penyewa. Peringkat 1: firma akauntan ("akaun HQ") dengan kakitangan sendiri. Peringkat 2: setiap klien HQ ("sub-akaun Klien") dengan pengguna sendiri, memuat naik penyata bank dan resit sendiri. Sistem menguraikan penyata bank kepada transaksi, memadankan resit yang dimuat naik terhadap transaksi tersebut mengikut jumlah + kedekatan tarikh + persamaan teks, dan mengira peratusan penyiapan bagi setiap klien setiap bulan kalendar. HQ melihat setiap klien dalam satu jadual boleh susun.

Pelanggan sasaran

Pembeli utama: rakan kongsi firma akauntan/pembukuan yang menguruskan 50+ klien SME. Pengguna sekunder, tiada kuasa membeli: kakitangan klien SME sendiri (pemilik, jurubuku, atau kakitangan pentadbiran) yang melakukan muat naik sebenar.

Fungsi teras

1. Pengambilan penyata bank → pengekstrakan transaksi
2. Muat naik resit/dokumen → pengekstrakan OCR bagi jumlah, tarikh, pembekal (P1: kategori cadangan)
3. Enjin padanan: resit yang diekstrak ↔ transaksi (dan kemudian, transaksi ↔ e-Invois MyInvois)
4. Peratusan penyiapan bagi setiap klien, setiap bulan + senarai jurang bernama
5. Papan pemuka merentasi klien untuk HQ, disusun mengikut penyiapan
6. Sistem peringatan untuk klien yang ketinggalan

Peranan pengguna

Peraturan perniagaan utama

• Sub-akaun klien hanya boleh tergolong dalam satu akaun HQ. Klien tidak boleh dikongsi antara dua firma akauntan dalam model ini (ditandakan sebagai andaian — klien sebenar kadangkala bertukar firma pertengahan tahun; laluan migrasi tidak direka untuk P0).
• % penyiapan dikira bagi setiap bulan kalendar, dikira semula secara langsung apabila muat naik baharu tiba — tidak pernah menjadi snapshot statik.
• Transaksi "sepadan" jika resit atau rekod e-Invois wujud dengan jumlah yang sama (± sedikit toleransi untuk yuran bank) dan tarikh dalam jendela yang boleh dikonfigurasi (lalai 10 hari) daripada tarikh transaksi. Di bawah ambang keyakinan, ia dibariskan sebagai "perlu pengesahan manual," bukan dipadankan secara senyap.
• Kakitangan HQ boleh melihat semua data klien di bawah akaun mereka; klien tidak boleh melihat data klien lain, walaupun dalam akaun HQ yang sama.

Produk Boleh Jual Minimum

Satu akaun HQ, boleh menjemput sub-akaun klien, di mana setiap klien boleh memuat naik penyata bank dan gambar resit (diekstrak OCR secara automatik), dan HQ melihat jadual semua kliennya dengan % penyiapan dan boleh klik masuk ke mana-mana klien untuk melihat senarai jurang bernama. Tiada MyInvois, tiada pengkategorian AI, tiada WhatsApp — muat naik, ekstrak OCR, padan, dan laporkan.

Monolit modular. Tiada mikroservis berasingan — "enjin padanan" adalah modul dalam aplikasi yang sama, bukan perkhidmatan yang digunakan secara berasingan, sehingga beban sebenarnya memerlukan.

flowchart LR
  subgraph Client["Pelayar - Pengguna HQ dan SME"]
    UI["Aplikasi Next.js
(App Router)"]
  end
  subgraph App["Vercel - Lapisan aplikasi"]
    API["Laluan API
(pengesahan, muat naik, papan pemuka)"]
    Parser["Modul penghurai penyata
(PDF/CSV ke transaksi)"]
    OCR["Modul pengekstrakan OCR/AI
(resit ke jumlah, tarikh, pembekal)"]
    Matcher["Modul enjin padanan
(resit diekstrak ke transaksi)"]
    Jobs["Tugas latar belakang
(Vercel Cron)"]
  end
  subgraph Data["Lapisan data terurus"]
    DB[("Postgres
Neon atau Supabase")]
    Storage[("Storan objek
Supabase Storage atau R2")]
  end
  subgraph Ext["Perkhidmatan luaran"]
    Email["Pembekal e-mel
cth. Resend"]
    WA["API WhatsApp Business
(P1)"]
    OCRAPI["Pembekal OCR/AI
(cth. Google Document AI,
AWS Textract, atau LLM multimodal)"]
  end
  UI -->|HTTPS| API
  API --> Parser
  API --> OCR
  API --> Matcher
  API --> DB
  API --> Storage
  OCR -->|panggilan async| OCRAPI
  OCR --> Matcher
  Jobs --> Matcher
  Jobs --> Email
  Jobs -.->|P1| WA
  Matcher --> DB
    

Tindanan yang disyorkan

Penguraian penyata — risiko teknikal sebenar

Bank Malaysia mengeksport penyata dalam susun atur PDF dan susunan lajur CSV yang tidak konsisten. Reka bentuk secara khusus untuk ini: corak adapter penghurai mengikut bank (satu modul penghurai kecil bagi setiap format bank), dengan fallback generik yang meminta pengguna memetakan lajur secara manual pada muat naik pertama jika format tidak dikenali. Jangan cuba membina satu penghurai sejagat yang mengendalikan setiap bank terlebih dahulu — tambah adapter apabila bank klien rintis sebenar ditemui.

Pengekstrakan OCR — jangan bina dari awal

Gunakan API OCR/dokumen-AI sedia ada (Google Document AI, AWS Textract, atau panggilan LLM multimodal dengan prompt output berstruktur) berbanding melatih atau membina penghuraian resit sendiri — ini masalah yang sudah diselesaikan dan masa pembangun solo lebih baik digunakan untuk logik padanan, iaitu pembeza sebenar. Anggap output OCR sebagai cadangan, bukan kebenaran mutlak: isi awal medan jumlah/tarikh/pembekal tetapi biarkan klien atau akauntan membetulkannya sebelum rekod digunakan untuk padanan, kerana jumlah yang salah dibaca boleh secara senyap menghasilkan padanan palsu atau jurang palsu.

Keselamatan, pemantauan, sandaran

• Penyata bank dan resit adalah data kewangan sensitif — sulitkan semasa rehat (diurus oleh pembekal storan), hadkan akses melalui URL bertandatangan berhad masa, jangan sekali-kali hidangkan fail secara awam.
• Log audit siapa melihat/memuat turun dokumen klien mana — firma akauntan akan bertanya tentang ini semasa perbincangan jualan memandangkan sensitiviti data.
• Sandaran platform terurus standard (pemulihan titik-masa Neon/Supabase) mencukupi pada skala MVP; tiada infrastruktur sandaran tersuai diperlukan lagi.

Operasi teras: enjin padanan

flowchart TD
  A["Klien muat naik penyata bank"] --> B["Penghurai ekstrak transaksi
(tarikh, jumlah, keterangan)"]
  B --> C["Transaksi disimpan,
status: belum sepadan"]
  D["Klien muat naik gambar resit"] --> D1["OCR ekstrak jumlah, tarikh,
pembekal; cadangkan kategori"]
  D1 --> D2{"Klien/akauntan sahkan
data yang diekstrak betul?"}
  D2 -- "tidak, betulkan" --> D1
  D2 -- "ya" --> E["Pemadan bandingkan resit disahkan
dengan transaksi belum sepadan"]
  C --> E
  E --> F{"Jumlah + jendela tarikh
+ persamaan teks
melebihi ambang?"}
  F -- "ya, keyakinan tinggi" --> G["Padan automatik,
transaksi ditandakan sepadan"]
  F -- "sempadan" --> H["Baris untuk pengesahan manual
oleh klien atau kakitangan HQ"]
  F -- "tiada padanan ditemui" --> I["Transaksi kekal belum sepadan,
muncul dalam senarai jurang"]
  H --> J{"Disahkan oleh pengguna?"}
  J -- "ya" --> G
  J -- "tidak / ditolak" --> I
  G --> K["% penyiapan dikira semula
untuk klien itu, bulan itu"]
  I --> K
    

Peranan & kebenaran pengguna

flowchart TD
  HQAdmin["hq_admin"] -->|urus| HQStaff["hq_staff"]
  HQAdmin -->|jemput &
keluarkan| Clients["akaun client_owner"]
  HQAdmin -->|lihat| AllDash["Semua papan pemuka klien"]
  HQStaff -->|lihat| AllDash
  HQStaff -->|semak| Ambiguous["Padanan samar,
mana-mana klien"]
  ClientOwner["client_owner"] -->|jemput| ClientStaff["client_staff"]
  ClientOwner -->|muat naik ke| OwnData["Penyata & resit sendiri sahaja"]
  ClientStaff -->|muat naik ke| OwnData
    

Langganan & pembayaran (andaian lalai: HQ bayar, mengikut tempat duduk)

flowchart TD
  A["HQ tandatangan perjanjian rintis
(5-10 tempat duduk klien)"] --> B["HQ masukkan kaedah pembayaran"]
  B --> C["Platform mengebil HQ setiap bulan,
mengikut tempat duduk klien aktif"]
  C --> D{"HQ tambah
lebih ramai klien?"}
  D -- "ya" --> E["Bilangan tempat duduk meningkat,
invois seterusnya mencerminkannya"]
  D -- "tidak" --> F["Caj bulanan tetap
diteruskan"]
  E --> G["HQ mengebil kliennya sendiri
secara berasingan
(di luar platform ini)"]
  F --> G
    

Aliran kerja pentadbiran — HQ mengejar klien yang ketinggalan

flowchart TD
  A["Tugas cron bulanan berjalan
pada 25hb"] --> B{"Klien di bawah
80% sepadan?"}
  B -- "tidak" --> C["Tiada tindakan diperlukan"]
  B -- "ya, ketinggalan" --> D["Peringatan e-mel automatik
dihantar kepada klien"]
  D --> E{"Klien muat naik
dalam 5 hari?"}
  E -- "ya" --> F["% dikira semula,
klien keluar daripada senarai ketinggalan"]
  E -- "tidak" --> G["Kakitangan HQ nampak klien ditanda
dalam papan pemuka mereka,
susuli secara terus"]
    

Gambar rajah Hubungan Entiti

erDiagram
  HQ_ACCOUNT ||--o{ HQ_USER : employs
  HQ_ACCOUNT ||--o{ CLIENT_ACCOUNT : manages
  CLIENT_ACCOUNT ||--o{ CLIENT_USER : employs
  CLIENT_ACCOUNT ||--o{ STATEMENT_UPLOAD : submits
  CLIENT_ACCOUNT ||--o{ TRANSACTION : has
  CLIENT_ACCOUNT ||--o{ RECEIPT : uploads
  STATEMENT_UPLOAD ||--o{ TRANSACTION : produces
  TRANSACTION ||--o| MATCH : "resolved by"
  RECEIPT ||--o| MATCH : "resolved by"
  CLIENT_ACCOUNT ||--o{ MONTHLY_SUMMARY : generates

  HQ_ACCOUNT {
    uuid id PK
    string name
    string billing_status
    int seat_count
  }
  HQ_USER {
    uuid id PK
    uuid hq_account_id FK
    string email
    string role
  }
  CLIENT_ACCOUNT {
    uuid id PK
    uuid hq_account_id FK
    string name
    string status
  }
  CLIENT_USER {
    uuid id PK
    uuid client_account_id FK
    string email
    string role
  }
  STATEMENT_UPLOAD {
    uuid id PK
    uuid client_account_id FK
    string file_url
    string bank_name
    string parse_status
    timestamp uploaded_at
  }
  TRANSACTION {
    uuid id PK
    uuid client_account_id FK
    uuid statement_upload_id FK
    date txn_date
    decimal amount
    string description
    string match_status
  }
  RECEIPT {
    uuid id PK
    uuid client_account_id FK
    string file_url
    decimal extracted_amount
    date extracted_date
    string extracted_vendor
    string suggested_category
    string ocr_confidence
    boolean confirmed_by_user
    timestamp uploaded_at
  }
  MATCH {
    uuid id PK
    uuid transaction_id FK
    uuid receipt_id FK
    string confidence
    string confirmed_by
    timestamp matched_at
  }
  MONTHLY_SUMMARY {
    uuid id PK
    uuid client_account_id FK
    string month
    int total_transactions
    int matched_transactions
    decimal completion_pct
  }
    

Model penyewaan

Dua peringkat, dikuatkuasakan dalam setiap pertanyaan: hq_account_id menetapkan skop akses kakitangan HQ merentasi semua klien mereka; client_account_id menetapkan skop pengguna klien kepada data sendiri sahaja. Setiap jadual di bawah peringkat akaun membawa kedua-dua kunci asing (secara terus atau melalui join) supaya pertanyaan tidak boleh secara tidak sengaja bocor merentasi akaun HQ atau merentasi klien dalam HQ yang sama.

Titik akhir API teras

Semua titik akhir memerlukan sesi yang ditetapkan skop sama ada hq_account_id atau client_account_id; permintaan merentasi penyewa mengembalikan 403, bukan hasil kosong yang ditapis, supaya pepijat kawalan akses gagal dengan jelas dan bukan secara senyap.

Dua aplikasi berasingan berkongsi satu pangkalan kod, dikawal mengikut peranan semasa log masuk.

Gaya visual

Minimal, profesional, padat data tetapi tidak bersepah — lebih hampir dengan alat kewangan/operasi berbanding aplikasi pengguna, kerana pangkalan pengguna utama (kakitangan firma akauntan) menghabiskan sepanjang hari dalam antara muka seperti hamparan dan akan menilai kredibiliti sebahagiannya berdasarkan betapa "serius" alat itu kelihatan. Responsif ke mudah alih khusus untuk aliran muat naik sisi klien, kerana pemilik SME sering mengendalikan ini daripada telefon.

Keputusan bahasa produk — keputusan sebenar, bukan togol untuk ditangguhkan

Aplikasi muat naik klien lalai kepada Bahasa Malaysia, bukan Bahasa Inggeris, kerana pengguna akhir sebenar produk ini — pemilik SME, jurubuku, dan kakitangan pentadbiran di klien firma — kebanyakannya penutur BM dalam urusan harian perniagaan. Setiap label, mesej ralat, e-mel/WhatsApp peringatan, dan teks keadaan kosong dalam aplikasi berhadapan klien dihantar dalam BM dahulu. Togol Bahasa Inggeris boleh wujud untuk minoriti klien yang lebih suka, tetapi ia bukan lalai dan bukan tempat usaha reka bentuk diberi keutamaan.

Papan pemuka penyeliaan HQ kekal dalam Bahasa Inggeris yang jelas secara lalai — rakan kongsi dan kakitangan firma akauntan yang menyemak jadual pelbagai klien selesa dengan alat B2B Bahasa Inggeris, dan Bahasa Inggeris juga bahasa pelan ini ditulis untuk pengasas. Togol BM untuk kakitangan HQ adalah tambahan P1 yang munasabah, bukan keperluan pelancaran.

Ini keputusan produk langsung, bukan "nice-to-have": menghantar aplikasi klien dalam Bahasa Inggeris dahulu dan "menambah BM kemudian" berisiko kepada masalah kepercayaan dan penerimaan yang sama seperti ditandakan dalam B·7 — klien yang tidak faham sepenuhnya apa yang diminta untuk dimuat naik kurang berkemungkinan membina tabiat menangkap gambar resit setiap hari yang produk ini bergantung padanya.

Sengaja tidak termasuk dalam pelan ini: integrasi MyInvois, peringatan WhatsApp, cadangan kategori AI, pemformatan lejar/eksport, dan skala kepada 200 klien — semuanya ditangguhkan sehingga rintis membuktikan logik OCR-dan-padanan teras berfungsi pada data bank dan resit Malaysia sebenar, iaitu ketidakpastian terbesar.

Andaian komersial yang mesti disahkan sebelum — atau sangat awal dalam — pembangunan

• Model pengebilan (lihat B.1): lalai kepada "HQ bayar mengikut tempat duduk, mengebil klien secara berasingan" — belum disahkan dengan firma sebenar.
• Kepercayaan: adakah klien SME firma akauntan sebenarnya akan memuat naik penyata bank sensitif kepada aplikasi vendor baharu yang tidak dikenali, atau adakah ini perlu dijenamakan semula di bawah jenama firma akauntan sendiri untuk mendapat penerimaan? Belum diselesaikan — perlu ditanya secara langsung dalam perbincangan rintis pertama.
• Laluan akses MyInvois: ditandakan dalam B.1 — sama ada P1 boleh dibina seperti yang dirancang bergantung pada jawapan yang imbasan ini tidak dapat sahkan.