Paying agent e fiscalità aggregata#

Il paying agent esegue cedole, rimborsi e altri pagamenti di servicing. CertiExch costruisce obbligazioni e istruzioni verificabili, ma non diventa il sistema fiscale del beneficiario finale.

Ripartizione dei ruoli#

CertiExch produce:

• posizione alla record date;
• quantità per conto di registrazione;
• evento e termini applicati;
• importo lordo;
• riepilogo fiscale aggregato ricevuto o applicabile;
• istruzione al paying agent;
• ricevute e riconciliazioni.

L’intermediario mantiene:

• identità del cliente finale;
• residenza e profilo fiscale;
• documentazione di esenzione;
• aliquota e regimi individuali;
• ripartizione locale tra wallet.

Il paying agent o sostituto d’imposta:

• riceve la provvista;
• applica ritenute e imposte secondo il proprio ruolo;
• esegue il pagamento;
• restituisce netto, imposte, scarti e ricevute;
• gestisce correzioni e recuperi.

Oggetti principali#

payment_obligation
tax_instruction_summary
paying_agent_instruction
payment_receipt
tax_receipt_summary
distribution_attestation
payment_correction

Questi oggetti devono rimanere correlati tramite instrument_id, event_id, registration_account_id, instruction_id e riferimenti del provider.

Stati dell’istruzione#

Il contratto operativo supporta una macchina a stati più ricca di online/offline:

draft
→ ready
→ submitted
→ received
→ accepted
→ pending_tax_validation / pending_funding
→ partially_processed / partially_paid
→ paid
→ reconciled

Sono inoltre possibili:

rejected
cancelled
correction_required
corrected

Non saltare direttamente da submitted a paid se il provider reale distingue accettazione, verifica fiscale e pagamento.

Provider simulato attuale#

Il provider simulato di base:

• controlla che lordo e netto siano coerenti;
• rifiuta importi non validi con amount_mismatch;
• restituisce accepted per un’istruzione coerente;
• calcola il netto come lordo meno ritenute e altre imposte dichiarate;
• produce un riferimento provider dimostrativo.

La console di servicing consente poi di esercitare stati e correzioni più articolati. Il provider simulato non esegue un adempimento fiscale reale.

Importi da non confondere#

La somma delle componenti deve quadrare con il lordo secondo il contratto e le regole di arrotondamento.

Profilo fiscale aggregato#

Nel core può esistere un riferimento come:

tax_profile_reference
tax_document_status
calculation_responsible_party
tax_receipt_reference

Non devono essere caricati nel core, salvo base giuridica e modello espliciti:

• residenza fiscale individuale;
• aliquota del singolo beneficiario;
• documento di esenzione del cliente;
• costo fiscale individuale;
• dati personali completi del beneficiario effettivo.

Flusso di cedola#

Pagamento parziale#

Un pagamento parziale deve conservare:

• importo originario;
• importo pagato;
• saldo residuo;
• motivo;
• conti interessati;
• ricevute multiple;
• stato della documentazione fiscale;
• piano di completamento o compensazione.

Non chiudere l’evento come paid se restano obbligazioni non regolate.

Codici di eccezione#

Il contratto interno deve normalizzare almeno:

insufficient_funds
invalid_payment_coordinates
missing_tax_documentation
beneficiary_not_eligible
tax_profile_unavailable
amount_mismatch
duplicate_instruction
payment_rejected
partial_execution
late_correction
provider_unavailable

Il testo libero può accompagnare il codice, ma non sostituirlo.

Correzioni post-pagamento#

Possibili rimedi:

• recupero diretto;
• compensazione su un flusso successivo;
• rettifica fiscale;
• riemissione della ricevuta riepilogativa;
• pagamento integrativo;
• chiusura in perdita autorizzata.

Riconciliazione#

Per ogni evento verificare:

somma obbligazioni lorde
= lordo dell’evento

somma ritenute + altre imposte + netti + sospesi/scarti
= lordo trattato

somma ricevute monetarie
= netto effettivamente pagato

Le attestazioni di distribuzione dell’intermediario devono riferirsi alle stesse obbligazioni e non modificare la posizione autoritativa del conto di registrazione.