21 Jun 2025·8 menit
Cara Membangun Aplikasi Mobile untuk Struk Digital dan Pengeluaran
Panduan praktis untuk membuat aplikasi mobile yang menangkap struk, mengekstrak data dengan OCR, mengkategorikan pengeluaran, dan mengekspor ke alat akuntansi.
Panduan praktis untuk membuat aplikasi mobile yang menangkap struk, mengekstrak data dengan OCR, mengkategorikan pengeluaran, dan mengekspor ke alat akuntansi.
Sebelum memilih fitur atau desain layar, tentukan secara spesifik masalah yang Anda selesaikan. “Melacak pengeluaran” terlalu luas; sakit sebenarnya biasanya struk yang hilang, input manual yang melelahkan, dan siklus reimbursement yang lambat.
Tulis pernyataan masalah satu kalimat yang bisa Anda uji pada setiap keputusan:
“Bantu orang menangkap struk dalam beberapa detik, ubah menjadi expense lengkap secara otomatis, dan kirim tanpa mengejar detail yang hilang.”
Ini menjaga ruang lingkup tetap terkendali dan mencegah aplikasi Anda berubah menjadi alat keuangan umum.
Kebanyakan aplikasi struk digital melayani lebih dari satu audiens:
Pilih pengguna utama dulu (seringkali karyawan atau freelancer), lalu desain pengalaman tim-keuangan sebagai “lapisan review” daripada alur kerja inti.
Fokuskan versi pertama pada beberapa outcome:
Sepakati beberapa metrik yang mencerminkan nilai nyata:
Saat tujuan, pengguna, pekerjaan, dan metrik jelas, sisa pembangunan menjadi serangkaian trade-off yang terarah.
Sebelum memilih fitur atau layar, catat perjalanan end-to-end yang harus didukung aplikasi Anda. Alur yang jelas mencegah “pemindaian struk” jadi tumpukan alat terpisah.
Minimal, petakan jalur penuh:
Untuk setiap langkah, catat apa yang dilihat pengguna, data apa yang dibuat, dan apa yang harus terjadi otomatis (mis. total dihitung, mata uang dinormalisasi, pajak terdeteksi).
Tentukan titik masuk utama, karena ini membentuk UI dan asumsi backend Anda:
Pilih satu “start default” untuk MVP Anda, lalu dukung sisanya sebagai jalur sekunder.
Perjelas siapa bisa melakukan apa:
Rancang aturan alih tugas sejak awal (mis. kapan expense menjadi read-only, siapa yang bisa override, dan bagaimana perubahan dicatat).
Dokumentasikan realitas yang rumit: pengembalian/refund, split bill, multi-mata uang, tip, struk hilang, dan per diem. Meski tidak diotomasi penuh di v1, alur Anda harus punya jalan jelas yang tidak memblokir pengguna.
Model data yang baik membuat semuanya lebih mudah: pencarian lebih cepat, lebih sedikit edit manual, dan ekspor lebih bersih untuk akuntansi. Kuncinya memisahkan apa yang ditangkap pengguna (file asli) dari apa yang dipahami aplikasi Anda (field yang dinormalisasi untuk filter dan laporan).
Anggap Receipt sebagai bukti (file plus hasil ekstraksi) dan Expense sebagai catatan bisnis yang dipakai untuk reimbursement, pengecekan kebijakan, dan pelaporan.
Satu expense bisa punya satu receipt, banyak receipt (split payment), atau tidak punya receipt (entri manual), jadi modelkan hubungan ini fleksibel.
Rencanakan field capture_method agar Anda bisa berkembang melampaui scan kamera:
Field ini juga membantu troubleshooting kualitas dan tuning OCR/parsing nanti.
Simpan minimal di Expense (meski sumbernya dari OCR): merchant, tanggal, total, pajak, mata uang, metode pembayaran. Simpan teks mentah dan nilai yang dinormalisasi (mis. kode mata uang ISO, tanggal yang diparsing) agar edit dapat dibalik dan dapat dijelaskan.
Simpan juga metadata seperti:
merchant_normalized (untuk pencarian konsisten)transaction_last4 atau referensi tokenized kartu (untuk mencegah duplikat)timezone dan locale (untuk parse tanggal/pajak dengan benar)Simpan gambar/PDF mentah terpisah dari data yang diekstrak/dinormalisasi. Ini memungkinkan re-proses (OCR yang lebih baik nanti) tanpa kehilangan asli.
Rancang pencarian untuk pertanyaan nyata pengguna:
Index field ini sejak awal; ini pembeda antara “scroll selamanya” dan jawaban instan.
Sertakan kontrol retensi dalam skema Anda, bukan sebagai pemikiran belakangan:
Dengan bagian-bagian ini, aplikasi Anda bisa skala dari penangkapan pribadi ke kepatuhan perusahaan tanpa menulis ulang fondasi.
Capture struk adalah momen pengguna memutuskan apakah aplikasi Anda terasa mudah atau menyebalkan. Perlakukan kamera sebagai “scanner,” bukan alat foto: buat jalur default cepat, terarah, dan toleran.
Gunakan deteksi tepi live dan auto-crop sehingga pengguna tidak perlu membingkai sempurna. Tambahkan petunjuk halus yang bisa ditindaklanjuti (“Mendekat”, “Hindari bayangan”, “Tahan stabil”) dan peringatan silau ketika highlights menghilangkan kertas.
Multi-page capture penting untuk folio hotel dan struk item panjang. Biarkan pengguna menambah halaman dalam satu alur, lalu konfirmasi sekali.
Sedikit preprocessing sering meningkatkan akurasi lebih dari mengganti engine OCR:
Jalankan pipeline ini konsisten agar OCR melihat input yang dapat diprediksi.
OCR on-device bagus untuk kecepatan, penggunaan offline, dan privasi. OCR cloud bisa lebih baik untuk gambar berkualitas rendah dan layout kompleks. Pendekatan praktis adalah hybrid:
Jelaskan kapan upload terjadi dan beri pengguna kontrol.
Mulai dari field bernilai tinggi: merchant, tanggal, mata uang, total, pajak, dan tip. Line item berguna tapi jauh lebih sulit—anggap itu peningkatan.
Simpan skor kepercayaan per field, bukan hanya per receipt. Ini memungkinkan Anda menyorot hanya yang perlu perhatian (mis. “Total tidak jelas”).
Setelah scan, tampilkan layar review singkat dengan perbaikan satu ketukan (edit total, set tanggal, ganti merchant). Tangkap koreksi sebagai sinyal pelatihan: jika pengguna sering mengubah “TotaI” menjadi “Total”, ekstraksi Anda dapat belajar pola umum dan meningkat seiring waktu.
Capture yang baik hanya separuh pekerjaan. Untuk menjaga expense bersih (dan mengurangi bolak-balik), aplikasi Anda butuh kategorisasi cepat, metadata fleksibel, dan pengaman kuat terhadap duplikat.
Mulai dengan aturan deterministik yang bisa dipahami pengguna dan dikelola admin. Contoh: “Uber → Transport”, “Starbucks → Meals”, atau “USD + kode merchant bandara → Travel”. Aturan dapat diaudit, mudah dijalankan, dan bisa offline.
Di atas itu, tambahkan saran berbasis ML (opsional) untuk mempercepat entri tanpa mengambil alih kontrol. Jaga UI jelas: tampilkan kategori yang disarankan, alasan saran (mis. “berdasarkan merchant”), dan biarkan pengguna mengoverride dengan satu ketukan.
Akselerator ketiga adalah favorit pengguna: kategori yang sering dipakai per merchant, kategori yang dipin, dan “terakhir dipakai untuk proyek ini.” Ini sering mengungguli “AI” untuk kecepatan dunia nyata.
Sebagian besar organisasi butuh lebih dari kategori. Bangun field kustom seperti project, cost center, client, dan policy tags (mis. “billable”, “personal”, “recurring”). Buat bisa dikonfigurasi per workspace, dengan aturan required/optional tergantung kebijakan.
Split sering terjadi: tagihan hotel dibagi antar proyek, atau makan bersama yang dibagi per peserta.
Dukung membagi satu expense ke beberapa baris dengan kategori, proyek, atau peserta berbeda. Untuk pembayaran bersama, izinkan pengguna menandai “dibayar oleh” dan mengalokasikan bagian—sambil mempertahankan satu receipt dasar.
Jalankan pengecekan kebijakan saat simpan dan saat submit:
Untuk duplikat, gabungkan beberapa sinyal:
Saat mendeteksi duplikat, jangan langsung memblokir—tawarkan “Review” dengan detail berdampingan dan opsi aman “Keep both”.
Aplikasi struk & expense gagal atau berhasil berdasarkan reliabilitas: bisakah orang menangkap struk di kafe basement, percaya itu tidak hilang, dan menemukannya saat finance meminta? Keputusan arsitektur awal menentukan rasa sehari-hari itu.
Untuk MVP, tentukan apakah Anda mengoptimalkan kecepatan pengiriman atau pengalaman native terbaik.
Capture struk terjadi saat konektivitas tidak dapat diandalkan. Perlakukan ponsel sebagai tempat data pertama disimpan.
Gunakan antrean lokal: ketika pengguna submit struk, simpan gambar + draft expense secara lokal, tandai “pending”, dan sinkronkan nanti. Rencanakan retry (dengan exponential backoff), dan tentukan bagaimana menangani konflik sinkronisasi (mis. “server wins”, “latest wins”, atau “tanyakan pengguna” untuk kasus langka seperti jumlah yang diedit).
Kebanyakan tim butuh backend untuk:
Menjaga layanan-layanan ini modular membantu Anda mengganti provider OCR atau meningkatkan parsing tanpa membangun ulang app.
Index berpengaruh saat orang mencari “Uber” atau memfilter “Meals di Maret.” Simpan merchant ter-normalisasi, tanggal, total, mata uang, kategori, dan tag. Tambah index untuk query umum (rentang tanggal, merchant, kategori, status), dan pertimbangkan layer pencarian ringan jika “penyimpanan dan pencarian struk” adalah janji inti.
Gunakan background sync bila didukung, tapi jangan bergantung padanya. Tampilkan status sinkronisasi di dalam app, dan pertimbangkan push notification untuk event seperti “OCR siap”, “struk ditolak”, atau “expense disetujui”, sehingga pengguna tidak terus membuka app untuk memeriksa.
Jika ingin memvalidasi alur dengan cepat (capture → OCR → review → submit) sebelum investasi full custom build, platform vibe-coding seperti Koder.ai dapat membantu prototipe dan mengirim lebih cepat menggunakan antarmuka berbasis chat. Ini berguna terutama untuk membangun dashboard web pendukung dan layanan backend (mis. panel admin React plus API Go + PostgreSQL), iterasi dalam “planning mode”, dan rollback dengan snapshot saat Anda menguji pengguna nyata.
Struk dan expense mengandung detail sensitif pribadi dan perusahaan: nama, fragmen kartu, alamat, pola perjalanan, dan kadang ID pajak. Perlakukan keamanan dan privasi sebagai fitur produk, bukan hanya checklist kepatuhan.
Pilih metode login yang sesuai dengan cara aplikasi dideploy:
Gunakan TLS untuk semua panggilan jaringan, dan enkripsi data sensitif di server. Struk sering disimpan sebagai gambar atau PDF, jadi amankan media storage terpisah dari record database (private bucket, short-lived signed URLs, dan kebijakan akses ketat).
Di perangkat, cache sesedikit mungkin. Jika perlu penyimpanan offline, enkripsi file lokal dan lindungi akses di balik keamanan OS (biometrik/passcode).
Tentukan peran sejak awal dan buat izin eksplisit:
Tambahkan pengaman seperti akses “view-only” untuk auditor dan visibilitas terbatas untuk kategori sensitif (mis. medis).
Kumpulkan hanya yang diperlukan. Jika Anda tidak butuh nomor kartu lengkap atau lokasi tepat, jangan simpan. Jelaskan apa yang diekstrak dari struk, berapa lama disimpan, dan bagaimana pengguna bisa menghapusnya.
Pertahankan audit log untuk aksi kunci: siapa mengubah apa, kapan, dan mengapa (termasuk edit jumlah, kategori, dan approval). Ini membantu penyelesaian sengketa, review kepatuhan, dan troubleshooting integrasi.
Aplikasi struk & expense yang bagus terasa seperti jalan pintas: pengguna menghabiskan detik untuk menangkap, bukan menit untuk memperbaiki. Tujuannya mengubah “saya bayar” menjadi “siap dikirim” dengan sesedikit mungkin ketukan.
Sebagian besar tim bisa menangani 90% penggunaan nyata dengan enam layar:
Rancang layar-layar ini sebagai satu alur: capture → review → auto-save ke daftar → submit saat siap.
Prioritaskan capture satu tangan: tombol shutter besar, kontrol yang mudah dijangkau, dan aksi “Selesai” jelas. Gunakan smart defaults untuk menghindari entri berulang—isi mata uang, metode pembayaran, proyek/klien, dan kategori yang sering dipakai.
Di layar Review, gunakan “chip” dan aksi cepat (mis. Ganti kategori, Split, Tambah peserta) daripada form panjang. Edit inline lebih baik daripada mendorong pengguna ke halaman edit terpisah.
Orang tidak akan menerima automasi kecuali mereka memahaminya. Sorot field yang diekstrak (merchant, tanggal, total) dan tambahkan penjelasan singkat untuk saran:
Tandai kepercayaan secara visual (mis. Perlu perhatian untuk field berkepercayaan rendah) agar pengguna tahu ke mana melihat.
Saat kualitas capture buruk, jangan langsung gagal. Beri petunjuk spesifik: “Struk buram—mendekat” atau “Terlalu gelap—nyalakan flash.” Jika OCR gagal, sediakan retry states dan fallback manual cepat untuk hanya field yang hilang.
Gunakan tipografi yang terbaca, kontras kuat, dan target ketuk besar. Dukung input suara untuk catatan dan peserta, dan pastikan pesan error diumumkan oleh screen reader. Aksesibilitas bukan ekstra—ia mengurangi gesekan bagi semua pengguna.
Aplikasi capture struk jadi berguna ketika bisa mengalirkan expense lewat review, reimbursement, dan akuntansi dengan sedikit bolak-balik. Itu berarti membangun langkah approval yang jelas, mengekspor laporan yang bisa langsung dipakai, dan integrasi dengan alat yang sudah dipakai tim keuangan.
Buat workflow sederhana, dapat diprediksi, dan terlihat. Loop tipikal:
Detail desain penting: tunjukkan “apa yang berubah sejak pengiriman terakhir”, izinkan komentar inline pada baris tertentu, dan simpan setiap transisi status (Submitted → Approved → Exported, dll.). Juga tentukan sejak awal apakah approval terjadi per expense, per report, atau keduanya—tim finance sering prefer approve per report, sementara manager mungkin ingin spot-check line item.
Dukung ekspor umum agar pengguna tidak perlu membangun ulang laporan:
Jika menawarkan PDF packet, buat halaman ringkasan sesuai ekspektasi finance: total per kategori, mata uang, pajak, dan flag kebijakan (mis. “struk hilang”, “melebihi limit”).
Untuk platform populer (QuickBooks, Xero, NetSuite), integrasi biasanya berujung pada: membuat expense/bill, melampirkan file struk, dan mapping field dengan benar (vendor/merchant, tanggal, jumlah, kategori/account, pajak). Meski tidak mengirim integrasi native segera, sediakan webhook/API generik supaya tim bisa menghubungkan app Anda ke alat workflow mereka.
Untuk mengurangi masalah support, buat mapping bisa dikonfigurasi: izinkan admin memetakan kategori Anda ke account mereka dan set default per tim, proyek, atau merchant.
Pengguna paling peduli “kapan saya dibayar?” Meski payout terjadi di payroll, aplikasi Anda bisa melacak status reimbursement:
Jika Anda tidak bisa konfirmasi “Dibayar” otomatis, izinkan langkah serah manual atau impor payroll untuk merekonsiliasi status. Untuk perencanaan dan pertimbangan integrasi, membantu untuk menguraikan apa yang termasuk di setiap tier—melink ke /pricing menjaga ekspektasi jelas tanpa membebani pembaca dengan detail.
Aplikasi expense sukses ketika menghilangkan pekerjaan berulang, bukan saat punya daftar fitur terpanjang. Mulai dari loop paling kecil yang berguna dan buktikan bekerja untuk orang nyata yang membuat laporan pengeluaran nyata.
Bangun hanya yang diperlukan untuk menyelesaikan: capture → extract → categorize → export.
Artinya pengguna bisa memotret struk, melihat field kunci (merchant, tanggal, total) terisi, memilih atau mengonfirmasi kategori, dan mengekspor/berbagi laporan expense (CSV, PDF, atau ringkasan email sederhana). Jika pengguna tidak bisa menyelesaikan loop ini dengan cepat, fitur tambahan tidak akan menyelamatkan Anda.
Tulis apa yang sengaja tidak Anda bangun dulu:
Memiliki roadmap jelas mencegah scope creep dan memudahkan memprioritaskan feedback pengguna.
Lacak funnel dari capture ke submission:
Padukan ini dengan prompt ringan di-app seperti “Apa yang menjengkelkan tentang struk ini?” pada saat kegagalan.
Bangun set kecil beragam struk nyata (merchant berbeda, font, bahasa, foto kusut). Gunakan untuk evaluasi dan regression test agar kualitas OCR tidak menurun diam-diam.
Pilot dengan tim kecil selama 1–2 siklus pengajuan expense. Minta pengguna mengoreksi field yang diekstrak dan mengkategorikan struk; perlakukan koreksi itu sebagai data pelatihan/label. Tujuan bukan kesempurnaan—melainkan membuktikan alur memang konsisten menghemat waktu.
Jika tujuan Anda cepat sampai beta kerja, pertimbangkan menggunakan Koder.ai untuk membangun bagian pendukung (konsol admin, ekspor, dashboard job OCR, dan API inti) dari spesifikasi berbasis chat. Karena mendukung ekspor source code, deployment/hosting, dan snapshot dengan rollback, Anda bisa iterasi cepat dengan pilot user dan tetap memegang kepemilikan kode saat produk matang.
Bahkan aplikasi expense yang baik bisa tersandung di tempat yang sudah diprediksi. Merencanakan isu-isu ini sejak awal menghemat minggu kerja ulang dan banyak tiket support.
Struk nyata bukan foto studio. Kertas kusut, tinta pudar, dan terutama kertas thermal bisa menghasilkan teks parsial atau terdistorsi.
Untuk mengurangi kegagalan, pandu pengguna saat capture (auto-crop, deteksi silau, petunjuk “mendekat”) dan simpan gambar asli sehingga mereka bisa scan ulang tanpa memasukkan ulang semuanya. Anggap OCR sebagai “usaha terbaik”: tampilkan field yang diekstrak dengan indikator kepercayaan dan buat edit cepat. Pertimbangkan juga jalur fallback untuk scan berkepercayaan rendah (entri manual atau review manusia untuk struk bernilai tinggi).
Tanggal, mata uang, dan pajak bervariasi luas. Struk dengan “03/04/25” bisa berarti hal berbeda, dan aturan VAT/GST memengaruhi total yang disimpan.
Hindari format yang di-hardcode. Simpan jumlah sebagai angka plus kode mata uang, tanggal sebagai timestamp ISO, dan simpan teks struk mentah untuk audit. Bangun field pajak yang dapat menangani pajak inklusif/eksklusif dan beberapa baris pajak. Jika Anda ekspansi ke banyak bahasa, simpan nama merchant dalam bentuk asli tapi lokalize label UI dan nama kategori.
Gambar resolusi tinggi berat, dan upload lewat data seluler bisa lambat—menguras baterai dan membuat pengguna frustrasi.
Compress dan ubah ukuran di perangkat, upload di background dengan retry, dan gunakan antrean sehingga struk tidak “menghilang” saat jaringan drop. Cache struk dan thumbnail terbaru untuk browsing cepat. Batasi penggunaan memori agar tidak crash di ponsel lawas.
Total yang diubah, pengiriman duplikat, dan struk palsu muncul cepat di deployment nyata.
Tambahkan deteksi duplikat (merchant/jumlah/tanggal sama, teks OCR mirip, fingerprint gambar) dan flag edit mencurigakan (mis. total diubah setelah OCR). Simpan audit log immutable antara apa yang ditangkap dan apa yang diubah, dan minta justifikasi untuk override manual pada field sensitif kebijakan.
Pengguna akan minta ekspor, penghapusan, dan bantuan mengembalikan struk yang hilang.
Siapkan tooling support dasar: pencarian berdasarkan user/receipt ID, lihat status proses, jalankan ulang OCR, dan ekspor data atas permintaan. Tentukan incident response: apa yang terjadi jika OCR down, atau upload gagal? Runbook yang jelas dan halaman status sederhana (/status) mengubah kekacauan menjadi alur kerja yang dapat dikelola.
Peluncuran yang sukses bukan hanya “mengirimkan ke app store.” Itu menetapkan ekspektasi, mengamati perilaku dunia nyata, dan mempersempit loop antara pengalaman pengguna dan perbaikan tim Anda.
Tentukan SLA untuk dua momen yang paling penting bagi pengguna: pemrosesan struk (OCR) dan sinkronisasi antar perangkat.
Misalnya, jika OCR biasanya selesai dalam 10–30 detik tapi bisa lebih lama di jaringan buruk, komunikasikan langsung: “Memproses struk… biasanya di bawah 30 detik.” Jika sinkronisasi bisa tertunda, tampilkan status ringan seperti “Disimpan lokal • Menyinkronkan” dan opsi retry. Isyarat kecil ini mencegah tiket support dan upload berulang.
Lacak indikator kecil yang mengungkap masalah reliabilitas lebih awal:
Alert saat ada lonjakan, dan review tren mingguan. Penurunan confidence OCR sering menandakan pergantian vendor, update kamera, atau format struk baru di lapangan.
Tambahkan tombol feedback di-app dekat layar detail struk, tempat frustrasi terjadi. Permudah koreksi, lalu review "correction logs" teragregasi untuk mengidentifikasi kesalahan parsing umum (tanggal, total, pajak, tip). Gunakan daftar itu untuk memprioritaskan pembaruan model/aturan.
Setelah capture dan pencarian stabil, pertimbangkan:
Tawarkan walkthrough 60 detik, contoh struk yang bisa diedit pengguna, dan halaman tip “hasil terbaik” singkat (pencahayaan bagus, permukaan datar). Link ke /help/receipts untuk referensi cepat.
Mulailah dengan pernyataan masalah yang sempit dan bisa diuji (mis. “tangkap struk dalam beberapa detik, buat expense otomatis, kirim tanpa detail yang hilang”). Lalu pilih pengguna utama (karyawan atau freelancer) dan tentukan 2–4 metrik keberhasilan yang terukur seperti:
Keterbatasan ini mencegah aplikasi mengembang menjadi alat keuangan umum.
Loop MVP praktis adalah: capture → extract → categorize → export/submit.
Pada v1, prioritaskan:
Tunda line item, card feeds, kebijakan lanjutan, dan integrasi mendalam sampai loop ini benar-benar menghemat waktu.
Petakan alur penuh dari “bukti” sampai “yang bisa dibayar”:
Untuk setiap langkah, tentukan apa yang terjadi otomatis, apa yang dilihat pengguna, dan data apa yang tercipta. Ini mencegah membangun alat terpisah yang tidak menyelesaikan perjalanan reimbursement.
Pilih satu start default untuk MVP (biasanya kamera) dan tambahkan lainnya sebagai jalur sekunder:
Pilihan ini memengaruhi UI dan asumsi backend (mis. preprocessing gambar vs. parsing HTML email/PDF). Lacak sumber dengan field capture_method sehingga Anda bisa mendiagnosis akurasi dan konversi per sumber.
Modelkan Receipt dan Expense sebagai dua record yang terhubung:
Jaga hubungan fleksibel: satu expense bisa punya beberapa receipt (pembayaran terpecah) atau tidak sama sekali (entri manual). Simpan teks OCR mentah dan field yang dinormalisasi agar edit dapat dijelaskan dan dibatalkan.
Buat pengalaman kamera yang berperilaku seperti scanner:
Sebelum OCR, jalankan preprocessing konsisten (deskew, koreksi perspektif, denoise, normalisasi kontras/lighting). Seringkali ini meningkatkan akurasi lebih efektif daripada mengganti vendor OCR.
Pendekatan hybrid biasanya paling praktis:
Apapun pilihan Anda, simpan kepercayaan per field (bukan hanya per receipt) dan bangun layar review cepat yang menyorot hanya yang perlu diperiksa (mis. “Total tidak jelas”). Transparan tentang apa yang memicu upload dan beri kontrol kepada pengguna.
Mulailah dengan aturan deterministik yang bisa dimengerti, lalu lapisi dengan saran ML:
Juga dukung field kustom seperti project, cost center, dan client supaya kategorisasi sesuai alur kerja nyata.
Gabungkan beberapa sinyal dan hindari pemblokiran keras:
Saat mendeteksi duplikat, tampilkan review berdampingan dan izinkan “Keep both.” Catat juga perubahan mencurigakan (mis. total diubah setelah OCR) dalam audit trail untuk ditinjau finance.
Bangun offline-first ke dalam alur inti:
Tampilkan status jelas seperti “Saved locally • Syncing” dan gunakan notifikasi untuk event penting (OCR siap, ditolak, disetujui). Ini membuat aplikasi dipercaya saat koneksi buruk.