Cash and bank management

Il modello dati: bank group, bank account e ledger

In Cash and bank management ogni bank account appartiene a un bank group, che rappresenta l’istituto e raccoglie i dati anagrafici condivisi (indirizzo, codici di routing) dai conti che ne fanno parte. Il bank group non è un’etichetta di comodo: è il livello a cui si centralizza ciò che non va duplicato sul singolo conto, e l’esame lo usa spesso come distrattore rispetto al bank account.

Il bank account è definito per legal entity, ha una valuta e — punto decisivo per il legame con il ledger — un main account su cui vengono contabilizzate le transazioni. Il conto bancario non tiene saldi indipendenti dalla contabilità generale: ogni movimento genera scritture sul main account collegato, e il confronto fra saldo del bank account, saldo del main account e saldo comunicato dalla banca è esattamente ciò che la riconciliazione mette alla prova. Se i tre valori divergono, il problema è quasi sempre a monte (registrazioni fatte direttamente in general journal sul main account bancario, che non passano dal modulo bancario).

Pagamenti e formati file

I flussi in uscita e in entrata non nascono in Cash and bank management ma in accounts payable e accounts receivable: il modulo bancario ne subisce gli effetti. Il method of payment è l’oggetto che porta il formato del file elettronico da generare (tipicamente configurato tramite Electronic reporting, con formati di tipo ISO 20022 o formati locali della banca), oltre al payment account predefinito. Il bank account fornisce le coordinate; il method of payment fornisce le regole di generazione del file e, dove previsto, il comportamento di settlement. Funzioni come positive pay producono un file inviato alla banca per validare gli assegni emessi: è un controllo antifrode in uscita, non uno strumento di riconciliazione.

Riconciliazione manuale contro advanced bank reconciliation

La riconciliazione manuale (account reconciliation) parte dall’estratto conto cartaceo o PDF: si inserisce il saldo finale dichiarato dalla banca e si marcano come cleared le transazioni corrispondenti, finché la differenza va a zero. Non importa alcun file: tutto il lavoro di corrispondenza è dell’operatore. È adeguata a conti con poche decine di movimenti al mese e a implementazioni in cui non vale la pena configurare nulla.

La advanced bank reconciliation si abilita sul singolo bank account e cambia il processo: si importa l’estratto conto elettronico (formati come MT940, BAI2 o camt.054, gestiti come import di dati tramite Electronic reporting), le righe dello statement diventano oggetti in D365 e vengono confrontate con le bank transaction dell’applicazione tramite reconciliation matching rules. Le regole valutano criteri come importo, data (con tolleranza in giorni), tipo di transazione e riferimento del documento, e possono essere raggruppate in matching rule set applicati in sequenza: le righe che corrispondono vengono abbinate automaticamente e all’operatore restano solo le eccezioni da trattare a mano. Alcune regole possono anche generare le scritture per i movimenti che esistono solo sull’estratto conto (commissioni, interessi), così che il documento contabile nasca durante la riconciliazione.

Il trade-off è chiaro: l’advanced richiede setup (formato di import concordato con la banca, number sequence, regole di matching, test) e va scelta quando il volume di transazioni è alto, i conti sono molti o si vuole ridurre l’errore umano; la manuale resta valida per volumi bassi e per conti marginali. La scelta si fa per bank account, non per legal entity.

Cash flow forecast

La previsione dei flussi di cassa non è un modulo di data entry: è una vista calcolata che aggrega le transazioni attese — ordini di vendita e di acquisto aperti, fatture non ancora incassate o pagate, budget register entry, transazioni previste sui main account — usando i termini di pagamento per collocarle nel tempo. Richiede una configurazione preliminare (i main account e i posting profile devono essere marcati come rilevanti per il forecast) e un processo periodico di calcolo. Il risultato si consulta nei workspace dedicati alla liquidità, con proiezione in valuta di conto o in valuta transazione.

Trappole tipiche d’esame

• Serve importare l’estratto conto elettronico dalla banca e abbinare in automatico → advanced bank reconciliation: la riconciliazione manuale non importa alcun file; se lo scenario cita un formato bancario o l’abbinamento automatico, la risposta corretta non è mai “marca le transazioni come cleared”.
• Più conti presso lo stesso istituto con gli stessi dati di routing → bank group: l’informazione condivisa si configura una volta sul group, non ripetuta su ogni bank account; il conto porta solo ciò che è specifico (valuta, main account, numero).
• Le commissioni bancarie compaiono solo sull’estratto conto → matching rule che genera la scrittura, non correzione manuale a posteriori: l’errore tipico è registrare a parte in general journal e poi trovarsi la riga di statement non abbinata.
• Il cash flow forecast è vuoto o incompleto → manca il setup sui main account/posting profile o il calcolo periodico: non è una vista in tempo reale, quindi “aggiorna la pagina” o “registra la fattura” non risolvono lo scenario.
• Il file di pagamento ha il formato sbagliato → si agisce sul method of payment, non sul bank account: il conto fornisce le coordinate, il metodo di pagamento porta il formato di export.
• Il saldo del main account non torna con quello del bank account → cercare le registrazioni fatte direttamente in contabilità: un main account bancario lasciato aperto ai journal generici è la causa classica di differenze che la riconciliazione non riesce a chiudere.

L’esame MB-310 è attivo, con soglia di superamento 700/1000, ed è erogato solo in inglese e giapponese: allena i termini nella lingua d’esame anche se studi in italiano.