Che cos'è la riconciliazione a tre vie?

La riconciliazione a tre vie è il controllo su cui quasi ogni ufficio contabilità si appoggia per smettere di pagare merce mai arrivata, e questo lavoro lo fa bene. L’ordine dice cosa è stato richiesto, il DDT registra cosa il magazzino ha firmato in entrata, la fattura dichiara cosa il fornitore vuole incassare; quando i tre coincidono su articolo e quantità, la fattura supera il controllo di ricevimento. La trappola è dare per scontato che un match superato certifichi anche il prezzo. Non lo fa. La riconciliazione a tre vie conferma l’evasione — l’ordine è stato ricevuto nella quantità fatturata — ma non dice nulla su se il prezzo unitario sia quello che avete negoziato. La correttezza del prezzo vive in una verifica separata, con impostazioni e messaggi propri. Confondere le due cose è il motivo per cui prezzi sbagliati passano su merce ricevuta correttamente.

Che cosa controlla ciascuna via

La riconciliazione a tre vie confronta tre fonti prima che una fattura sia approvata al pagamento: l’ordine di acquisto (ciò che è stato concordato), il DDT (ciò che è stato ricevuto) e la fattura (ciò che viene addebitato). La fattura è liquidata solo quando tutti e tre coincidono su articolo e quantità. Togliete la via del DDT e resta la riconciliazione a due vie — ordine contro fattura soltanto — più veloce, ma che si fida della parola del fornitore sul fatto che la merce sia arrivata. Il DDT, il documento di trasporto, è l’equivalente italiano del goods receipt: è l’unico documento che registra cosa è davvero entrato in magazzino.

In SAP questa è la verifica fattura basata sull’entrata merci: la fattura è confrontata con la quantità registrata al ricevimento, non solo con l’ordine. Microsoft Dynamics 365 Finance la espone come una delle sei funzioni di matching dichiarate e riporta l’esito per ogni riga come stato Passed o Failed; su una riga verificata a due vie la colonna del match della quantità ricevuta resta vuota, perché non c’è un DDT da leggere.

Perché la riconciliazione a tre vie non vede un prezzo sbagliato

Un match a tre vie è un controllo di quantità. Si chiede se la quantità fatturata sia stata ordinata e ricevuta — e si ferma lì. Nulla nei tre documenti che legge gli dice quale prezzo avete negoziato, quindi un fornitore può fatturare una quantità ricevuta in modo impeccabile a un prezzo unitario sbagliato e il match passerà lo stesso. La correttezza del prezzo è verificata a parte, da un confronto di tolleranza, e se quel controllo blocchi davvero la fattura è una scelta di configurazione.

In SAP, quel controllo separato è uno scostamento di prezzo in fattura: il sistema confronta il prezzo di fattura calcolato con il prezzo netto d’ordine sotto una chiave di tolleranza dedicata, PP, ed emette M8 082 (una soglia assoluta) o M8 083 (una soglia percentuale). I messaggi di quantità — come M8 081, che segnala una quantità fatturata maggiore di quella del ricevimento merci — sono una famiglia del tutto diversa. I quattro motivi di blocco di SAP li tengono separati: Quantità, Prezzo, Qualità e Data.

Il guasto più sottile è quando il prezzo sembra sbagliato ma è giusto: un prezzo unitario corretto diviso per una quantità sbagliata produce uno scostamento e blocca la fattura come problema di prezzo, mentre la vera causa sono le unità. Il controllo prezzo riga per riga contro il listino concordato è il passo che la quantità non copre, descritto nella guida controllo fatture fornitori riga per riga contro il listino.

Dati disallineati contro dati affidabili: dove finisce la quantità e inizia il prezzo

Come controllare il prezzo quando la riconciliazione a tre vie non arriva

1. Usate la riconciliazione a tre vie per ciò in cui è brava. Confermate che ordine, DDT e fattura coincidano su articolo e quantità. Un match di quantità pulito è necessario — non è la prova che il prezzo sia giusto.

2. Aggiungete la verifica di prezzo che il match non vi dà. Confrontate ogni prezzo unitario fatturato con quello che avete davvero concordato — il contratto, o il listino in vigore alla data d’ordine. Un confronto tra listini fa emergere la differenza tra concordato e fatturato che la quantità non legge mai.

3. Controllate le unità sotto il prezzo. Un prezzo giusto diviso per la quantità sbagliata si calcola come uno scostamento di prezzo, quindi verificate che l’unità in cui il fornitore ha prezzato coincida con quella che avete ordinato e ricevuto. Un convertitore di unità e dimensioni conferma il coefficiente di conversione prima che trattiate il caso come una contestazione di prezzo.

4. Mantenete le unità su codici standard. Se ordine e fattura usano codici unità diversi per la stessa grandezza, le righe smettono di essere confrontabili. Un validatore di codici unità verifica che le unità corrispondano a codici standard validi prima del confronto.

5. Correggete il record di origine, non la singola fattura. Riscrivete il prezzo di contratto o il coefficiente di conversione corretto sull’articolo o sull’accordo, così che la fattura successiva lo erediti, invece di sbloccare un blocco dopo l’altro a mano.

Related

FAQ

Qual è la differenza tra riconciliazione a due vie e a tre vie? +

La riconciliazione a due vie confronta solo l’ordine di acquisto con la fattura fornitore — articolo, quantità e importo — e nient’altro. La riconciliazione a tre vie aggiunge il DDT, cioè il documento di trasporto: così la fattura viene liquidata solo per la quantità che il magazzino ha davvero registrato in entrata. È la via in più che intercetta le consegne parziali e le quantità fatturate ma mai ricevute. In Dynamics 365 Finance una riga verificata a due vie lascia vuota la colonna del match della quantità ricevuta, perché non esiste un DDT da leggere.

Una riconciliazione a tre vie superata garantisce che il prezzo sia corretto? +

No. La riconciliazione a tre vie conferma che la quantità fatturata è stata ordinata e ricevuta; non legge mai il prezzo che avete concordato, quindi una quantità ricevuta correttamente può comunque essere fatturata al prezzo unitario sbagliato e passare il controllo. La correttezza del prezzo è una verifica di tolleranza separata, con impostazioni proprie — in SAP, la chiave di tolleranza PP e i messaggi di scostamento prezzo M8 082 e M8 083. Se quel controllo si limita a segnalare, o se le sue soglie sono larghe, un prezzo sbagliato supera indisturbato un match di quantità pulito.

Che cosa verifica esattamente la riconciliazione a tre vie? +

Che l’ordine sia stato evaso come fatturato: l’articolo e la quantità in fattura coincidono con la quantità ordinata e con la quantità registrata sul DDT. È un controllo di evasione e di quantità. Non verifica l’accordo sul prezzo, la conformità al contratto, né che le unità di misura sotto il prezzo siano coerenti: questi sono controlli separati, se vengono eseguiti.

Come gestisce SAP la riconciliazione a tre vie? +

SAP usa la verifica fattura basata sull’entrata merci: la fattura è confrontata con la quantità registrata al ricevimento merci, non solo con l’ordine. Uno scostamento di quantità genera un messaggio come M8 081, che segnala una quantità fatturata maggiore di quella del ricevimento merci e il cui tipo è configurabile come errore o come avviso. Il prezzo è gestito da una famiglia diversa di chiavi di tolleranza e messaggi, e SAP tiene i due controlli distinti con quattro motivi di blocco: Quantità, Prezzo, Qualità e Data.

Dynamics 365 e Business Central supportano la riconciliazione a tre vie? +

Dynamics 365 Finance sì, come una delle sei funzioni di matching dichiarate; la riconciliazione a tre vie si attiva tramite la policy di matching della riga e ogni riga riporta lo stato Passed o Failed. Business Central è diverso: impone che non si possa mai fatturare più di quanto è stato ricevuto, ma non ha una policy di matching o un quadro di tolleranze di prezzo nativi, quindi i partner li aggiungono con estensioni. Non date per scontato che in Business Central esista un’impostazione di tolleranza per il match a tre vie già pronta.

Come aiuta Claro con la riconciliazione a tre vie? +

Claro non sostituisce il motore di matching del vostro ERP: sistema i dati contro cui quel motore confronta. Riconduce ogni riga del fornitore a un unico record di prodotto attendibile, con unità note, coefficienti di conversione e il prezzo concordato preso dal listino in vigore, così che sia il controllo di quantità sia la verifica separata del prezzo lavorino su cifre affidabili. Invece di inseguire un blocco di prezzo che è in realtà un errore di unità, o di scoprire un prezzo sbagliato mesi dopo in un recupero crediti, lo scostamento emerge sulla fattura: è il compito della riconciliazione delle fatture contro dati di catalogo attendibili.

REVIEW-NOTES

• Nessun numero o stringa di errore ERP inventato. Dynamics 365 è descritto solo tramite gli stati Passed/Failed, la colonna del match della quantità ricevuta vuota su riga a due vie e le sei funzioni di matching (appendice BRIEF). SAP: chiave di tolleranza PP con M8 082 (assoluta) / M8 083 (percentuale) e i quattro motivi di blocco (Quantità, Prezzo, Qualità, Data). M8 081 è citato per numero ma parafrasato («segnala una quantità fatturata maggiore di quella del ricevimento merci»), non quotato verbatim come short text: così si evita lo spot-check SE91 richiesto dalla regola di accuratezza 6 del BRIEF. Business Central: regola «mai fatturare più di quanto ricevuto» e assenza di policy di matching/tolleranze native, senza riprodurre testi di messaggio (Microsoft non li pubblica).
• Link inline solo a pagine esistenti (audit-checked): guides/sap-differenza-prezzo-fattura-ordine, guides/controllo-fatture-fornitori-listino, tools/price-list-diff, tools/unit-dimension-converter, tools/unit-code-validator — tutte verificate presenti. Tre link a strumenti inline (≥2 come richiesto). L’esterno /by-use-case/invoice-reconciliation è gestito dalla CTA automatica, non nel body.
• Fratello IT non ancora pubblicato: glossary/unita-di-misura-fattura nasce in questa stessa batch ed è referenziato solo come <Card> (non audit-checked), mai inline. Resta un link live rotto finché quel pezzo non è pubblicato; da ricablare eventualmente inline nel commit finale di wiring (BRIEF Workflow step 6).
• Fallback in inglese segnalati nel testo delle Card: glossary/three-way-matching (pendant EN, etichettato «la voce in inglese») e glossary/unit-of-measure («Voce in inglese»), perché non esiste ancora un pendant nativo equivalente.
• relatedSlugs omesso di proposito per non far fallire l’audit sul fratello IT inesistente, e translations non impostato come da istruzioni: va aggiunto in entrambe le direzioni verso glossary/three-way-matching quando si decide la strategia hreflang EN↔IT per il cluster.
• Localizzazione CTA. Il blocco CTA è reso da resolveCta() (learn-more), hardcoded in inglese. Per ottenere «Come Claro lo risolve in produzione» / «Scopri di più» serve la modifica condivisa a resolveCta()/ArticleCta segnalata in SCHEMA-NOTES §4 (decisione aperta per i batch IT/DE). Finché non è risolta, la CTA potrebbe comparire in inglese: non è un difetto di questo file.