Cheque issue register — શું record કરવું, અને auditors એ કેમ માંગે છે (2026)
Audit season, એક Tuesday ની બપોર. Table ની પેલે પાર બેઠેલો article clerk bank statement માંથી એક line વાંચે છે: cheque number 004312, ₹1,86,000, 4 March ના રોજ debit. પછી સવાલ. "આ payment શેના માટે હતી?"
જો answer "જોઈને કહું છું" થી શરૂ થાય અને ચાળીસ minute પછી ત્રણ cheque books ની counterfoils ફેરવતાં પૂરો થાય — જેમાંથી બે ખતમ થઈ ચૂકી છે, એવા drawer માં filed જેના પર કોઈ label નથી — તો problem કોઈની memory નથી. Business પાસે cheque issue register છે જ નહીં.
આ post એ જ unglamorous fix છે. Register શું છે, એને exact કયા columns જોઈએ, એ payment voucher સાથે કેવી રીતે pair થાય છે, એની આસપાસના એ controls જે cheque misuse ને actually રોકે છે, અને એનું best version હાથથી maintain કેમ નથી થતું. આ cheque lifecycle management નો accounts-desk વાળો છેડો છે — એ જાણવું કે book અને bank statement ની વચ્ચે દરેક leaf ક્યાં ઊભી છે, જે દિવસે પણ પૂછાય.
ત્રણ સવાલ, એક નબળી system
Auditor ના cheque વાળા સવાલના હંમેશા ત્રણ ભાગ હોય છે, ભલે એ એક sentence માં આવે. Cheque 004312 શેના માટે હતો? કોણે approve કર્યો? Clear થયો કે નહીં?
હવે જુઓ તમારા answers અત્યારે ક્યાં રહે છે. Ledger ₹1,86,000 એક creditor ના account માં record કરે છે — પણ usually instrument number નહીં, અને approval તો ક્યારેય નહીં. Bank statement કહે છે "4 March ના debited" — cleared, હા; કેમ, ના. Counterfoil, જો એ સવારે ભરાઈ પણ હોય, તો ઉતાવળી handwriting માં એક payee name આપે છે અને બીજું કંઈ નહીં.
ત્રણ sources. કોઈ complete નહીં. અને આ ત્રણેયને જોડવું એ જ પેલી ચાળીસ-minute વાળી hunt છે — auditor જે પણ cheque sample કરે, દરેક માટે repeat.
Cheque issue register ત્રણેય answers ને એક line પર મૂકી દે છે. બસ આ જ આખો idea છે. એક running record, દરેક leaf ની એક row, cheque book આવવાના દિવસથી એના છેલ્લા cheque ના clear થવા સુધી.
Counterfoil એ register નથી
સાફ કહેવું જરૂરી છે, કારણ કે મોટાભાગના નાના businesses genuinely માને છે કે counterfoil જ એમનું register છે.
નથી, પાંચ કારણોસર. એ per-book છે — તમારી history દરેક એ book માં વિખરાયેલી છે જે તમે ક્યારેય પૂરી કરી. એ non-searchable છે — એક payee શોધવાનો મતલબ દરેક stub વાંચવો. એ ફક્ત એટલું record કરે છે જેટલું લખનારે બે-inch ની જગ્યામાં scribble કર્યું — જે દિવસના દસમા cheque પછી ઘણીવાર ફક્ત એક amount હોય છે. એના પર કોઈ status નથી — counterfoil એકસરખી દેખાય છે, ભલે cheque clear થયો હોય, bounce થયો હોય, કે હજુ કોઈના drawer માં પડ્યો હોય. અને book ખતમ થતાં જ એ કોઈ cupboard માં ગાયબ થઈ જાય છે, પોતાની દસ seconds ની history સાથે.
Counterfoils એક backup છે, system નહીં. ભરતા રહો. બસ એમને record ન સમજો.
એ columns જે પોતાની જગ્યા deserve કરે છે
આ રહ્યું format — નીચેનો દરેક column એટલા માટે exist કરે છે કારણ કે future નો કોઈ સવાલ એને માંગે છે. Ruled register, Excel sheet, કે software: fields એ જ છે.
| Column group | તમે શું record કરો છો | આ કયા સવાલનો answer છે |
|---|---|---|
| Instrument | લખવાની date, cheque number, bank + account | કઈ leaf, કઈ book માંથી, કયા account પર? |
| Payee અને amount | Payee નું name exactly જેવું લખ્યું, amount ₹ માં | કોને pay થાય છે, કેટલું? |
| Purpose | Purpose કે invoice reference, payment voucher number | આ payment exist જ કેમ કરે છે, approval ક્યાં છે? |
| People | Prepared by, authorised by | કોણે બનાવ્યો, કયા signatory એ sign કર્યો? |
| Status + clearance date | Issued / handed over / presented / cleared / returned / cancelled / stopped | આ cheque અત્યારે ક્યાં છે? |
| Remarks | Post-dated, replacement leaf, stop-payment નું કારણ, કંઈ પણ odd | આવતા quarter સુધીમાં તમે શું ભૂલી ગયા હશો? |
બે habits આ format ને કામનું બનાવે છે. દરેક leaf ની એક row — cancelled વાળી પણ, કારણ કે missing row એટલે missing cheque, અને missing cheque એટલે control failure. અને status column cheque ના move થતાં જ update — year end પર reconstruct નહીં. "Issued" એટલે લખાયો અને sign થયો. "Handed over" એટલે office માંથી નીકળ્યો. "Presented" એટલે clearing માં પહોંચ્યો. પછી cleared, કે returned — બંને case માં date સાથે.
એ status column જ register ની આખી personality છે. એના વગર તમારી પાસે એક list છે. એની સાથે તમારી પાસે outstanding liabilities નો live map છે, cheque-by-cheque.
Payment voucher — register નો બીજો અડધો ભાગ
Register જાણી જોઈને કેમ ને ફક્ત થોડા words માં record કરે છે. આખી વાર્તા payment voucher પર રહે છે, અને બંને documents એકબીજા તરફ point કરે છે.
કામની વહેંચણી: voucher approval carry કરે છે — પાછળ stapled invoice કે bill, account head, sanction કરનારો signature, date. Register instrument carry કરે છે — number, payee, amount, status. Voucher number register ની row માં જાય છે; cheque number voucher પર. એક link, બે વાર લખેલી.
Auditor exactly આ જ link trace કરે છે. Statement પર એક debit પસંદ કરો → register માં cheque number શોધો → એ row માંથી voucher number વાંચો → voucher કાઢો → એની પાછળ invoice અને approval signature મેળવો. ચાર hops, બે minute, done. Chain intact હોય તો cheque verification audit નો સૌથી ઝડપી ભાગ છે. તૂટેલી હોય — register માં voucher number નહીં, કે vouchers month થી filed અને cheques number થી search થાય — તો દરેક sampled payment એક ખોદકામ બની જાય છે.
Vouchers ને sequentially number કરવા, financial year પ્રમાણે, એ નાનું discipline છે જે chain ને honest રાખે છે. Voucher numbers નો gap પણ એટલી જ ઝડપથી પૂછાય છે જેટલો cheque numbers નો.
પાંચ controls જે format થી વધારે matter કરે છે
નબળા controls વાળું સુંદર રીતે ruled register decoration છે. આ પાંચ કોઈ પણ column layout થી વધારે matter કરે છે:
1. Sequential numbering, કોઈ unexplained gap નહીં. Cheque numbers printed sequence માં ચાલે છે — તો register ને પણ ચાલવું પડશે. જો 004311 અને 004313 entered છે અને 004312 નહીં, તો કોઈ આજે explain કરે, March માં નહીં.
2. Cancelled leaves રખાય છે, marked અને entered. બગડેલી leaf પર CANCELLED લખાય છે, એ book માં stapled રહે છે કે vouchers સાથે filed, અને એને પોતાની register row મળે છે. Cancelled cheque ક્યારેય ફેંકો નહીં — destroyed leaf અને stolen leaf માં ફરક નથી દેખાતો.
3. Blank books signatory થી દૂર રહે છે. જે person cheques sign કરે છે, એ જ unsigned cheques નો stock પણ ન રાખે. Basic separation — મોટાભાગની નાની firms માં skip, કારણ કે "બધું એક જ cupboard માં છે". Misuse એ જ cupboard થી શરૂ થાય છે.
4. એક threshold ની ઉપર dual authorisation. ધારો કે ₹1,00,000 ની ઉપર બે signatures — figure તમારી પોતાની છે, અને board resolution નક્કી કરે છે કોણ sign કરી શકે. Register નો "authorised by" column એ જગ્યા છે જ્યાં તમે prove કરો છો કે rule follow થયો.
5. Bank statement સાથે monthly tie-out. Statement ને register ની સામે reconcile કરો — memory ની સામે નહીં. દરેક debit એક register row સાથે match થાય; મહિનાથી જૂની દરેક "issued" row પર question mark લાગે. મહિનાની ત્રીસ minute, કે year end પર એક ખોવાયેલું અઠવાડિયું. Choice તમારી.
Auditor actually શું માંગશે
થોડા year-ends કરી લીધા પછી requests predictable છે. પાંચ items, લગભગ દરેક વખતે.
31 March ની unpresented cheque list — દરેક cheque જે issue થયો પણ હજુ clear નહીં. Status column હોય તો આ એક filter છે. ન હોય, તો આ તમારા bank reconciliation નો દુઃખદાયક ભાગ છે, counterfoils માંથી rebuilt.
Sign થયા પણ handed over ન થયા હોય એ cheques. 30 March ના લખાયેલો અને 15 April ના પણ office ના drawer માં પડેલો cheque એક cut-off સવાલ ઊભો કરે છે: liability ખરેખર આ જ વર્ષે discharge થઈ? "Handed over" status exactly આના માટે જ exist કરે છે.
Reconciliation માં હજુ પણ સવાર stale cheques. નીચે detail માં — આ જ એ item છે જેમાં દરેક SMB fail થાય છે.
Cancelled leaves, physically. Auditor register માંથી cancelled rows પસંદ કરશે અને mutilated leaf જોવા માંગશે. દસ second માં produce કરી દો, sample size નાની રહેશે.
એક sequence check. વર્ષનો પહેલો અને છેલ્લો used cheque number, અને વચ્ચેની દરેક missing વસ્તુની explanation.
આમાંથી કોઈ trick question નથી. બધા એક જ સવાલ છે — આ business પોતાના cheques ને control કરે છે, કે cheques એને? — પાંચ રીતે પૂછાયેલો.
જે register તમે memory થી update કરો છો, એ holes વાળું register છે. Auditor એ record પર ભરોસો કરે છે જે cheque સાથે એ જ moment પર બન્યો — એ નહીં જે April ના પહેલા અઠવાડિયામાં counterfoils માંથી reconstruct થયો.
Stale-cheque cleanup જે કોઈ schedule નથી કરતું
Cheque પોતાની date થી ત્રણ મહિના valid રહે છે. એ પછી bank એને pay નહીં કરે — પણ entry પોતાની જાતે સાફ નથી થતી. Firm-દર-firm, year-end reconciliation માં અગિયાર, ચૌદ, વીસ મહિના જૂના cheques "unpresented" તરીકે dutifully listed મળે છે — મર્યા પછી પણ ઘણા લાંબા સમય સુધી.
દરેક quarter, cleanup કરો. Register માં ત્રણ મહિનાથી જૂની "issued" rows filter કરો. દરેક માટે decide કરો: payee એ ખોઈ નાખ્યો, તો fresh cheque reissue કરો (જૂની row ને stale mark કરીને, doubt હોય તો stop-payment સાથે); કે payment હવે owed જ નથી, તો books માં entry reverse કરો અને row close કરો. બંને રીતે row ને એક ending મળે છે. જે register માં દરેક cheque આખરે cleared, returned, cancelled, stopped કે stale-written-back સુધી પહોંચે છે, એ register પોતે reconcile થાય છે.
Quarter ની વીસ minute છે. લગભગ કોઈ નથી કરતું. એ accounts department બનો જે કરે છે.
જ્યારે register પોતે લખે છે
ઉપરનું બધું paper પર કામ કરે છે. ઘણી disciplined firms decades થી ruled register ચલાવે છે. પણ notice કરો આખું apparatus શેના પર ટકેલું છે: એક માણસ, જે દિવસની સૌથી busy moment પર, દરેક વખતે, એક row લખવાનું યાદ રાખે. System નું hole આ જ છે — format નહીં, entry ની moment.
Printing economics પૂરેપૂરી બદલી નાખે છે. જ્યારે cheques handwritten ની જગ્યાએ software થી print થાય છે, register એક અલગ chore નથી રહેતું: record print થવાની ક્રિયાથી બને છે. Cheque number, date, payee, amount, account — એ જ moment પર capture, જ્યારે leaf printer માંથી નીકળે છે; હંમેશ માટે searchable; status issue થી clearance સુધી tracked; અને reconciliation કોઈની memory ના બદલે register ની સામે. ત્રીસ vendor cheques ના એક bulk run પર, આ ત્રીસ register rows છે જે કોઈએ લખવાનું યાદ નથી રાખવું પડ્યું.
"Cheque 004312 શેના માટે હતો?" એક two-second search બની જાય છે. જે, વિચારો તો, આ સવાલનો હક હંમેશાથી હતો.
એ register જે પોતે લખે છે. તમારા cheques Cheqify થી print કરો અને દરેક leaf print થતાં જ log થઈ જાય છે — number, payee, amount, status issue થી clearance સુધી tracked, 300+ Indian bank layouts પર searchable. 100% free. app.cheqify.app પર start કરો.
