View source for Split Payment e Reforma Tributária com IA arquitetura determinística para pagamentos, conciliação e soberania fiscal

{{DISPLAYTITLE:Split Payment e Reforma Tributária: arquitetura determinística para pagamentos, conciliação e soberania fiscal}}

= Split Payment e infraestrutura fiscal determinística =

'''Como nossa infraestrutura conecta documento fiscal, pagamento, obrigação tributária e auditoria em um fluxo rastreável, interoperável e governado'''

https://i.ytimg.com/vi/35pEhb_BzZI/hqdefault.jpg

== Visão geral ==

O Split Payment representa uma transformação potencial na relação entre documentos fiscais, pagamentos, tributos, contribuintes, instituições financeiras, provedores de serviços de pagamento e plataformas governamentais.

Em uma arquitetura convencional, essas informações podem permanecer distribuídas entre sistemas fiscais, ERPs, adquirentes, bancos, PSPs, documentos XML, arquivos de conciliação e processos manuais.

Sob a ótica da '''determinar.ia.br''', o principal desafio não é apenas calcular ou separar valores. É preservar a identidade e a relação entre todos os eventos que participam da operação.

A infraestrutura deve ser capaz de responder:

* qual operação econômica originou o pagamento;

* qual documento fiscal representa a operação;

* qual obrigação tributária estava vigente;

* qual regra foi aplicada;

* qual valor foi atribuído a cada participante;

* qual PSP processou a transação;

* qual identificador relaciona os sistemas;

* quando ocorreu cada evento;

* qual versão da regra estava ativa;

* como divergências foram tratadas;

* quem autorizou ajustes;

* como a operação pode ser auditada.

A arquitetura parte de uma separação fundamental:

* o documento fiscal '''declara a operação conforme seu esquema e contexto''';

* o pagamento '''registra a movimentação financeira''';

* o motor tributário '''aplica regras e parâmetros vigentes''';

* o PSP '''executa funções autorizadas no fluxo de pagamento''';

* o grafo '''relaciona entidades, eventos, documentos, valores e estados''';

* o contribuinte '''mantém controles contábeis, fiscais e operacionais próprios''';

* a plataforma pública '''oferece os serviços definidos pela regulamentação e documentação oficial''';

* a auditoria '''preserva a cadeia entre cálculo, separação, liquidação e conciliação'''.

O objetivo não é substituir sistemas fiscais ou financeiros existentes. O objetivo é estabelecer uma camada de identidade, semântica, validação e proveniência entre eles.

== Princípio arquitetural ==

A arquitetura separa oito funções:

# '''Operação econômica''': venda, prestação, devolução, cancelamento ou ajuste;

# '''Documento fiscal''': representação da operação conforme o esquema aplicável;

# '''Obrigação tributária''': regra, base, alíquota, benefício, crédito e período;

# '''Ordem de pagamento''': instrumento, valor, pagador, recebedor e referência;

# '''Execução financeira''': processamento pelo PSP e demais participantes autorizados;

# '''Identidade transacional''': identificadores que relacionam os eventos;

# '''Conciliação''': comparação entre valores esperados, separados, liquidados e contabilizados;

# '''Auditoria''': preservação de fonte, regra, versão, autoria, estado e histórico.

Essa separação evita tratar nota fiscal, cálculo tributário e pagamento como se fossem o mesmo objeto.

== Lousa central da infraestrutura ==

    ┌──────────────────────────────────────────────────────────────────────────┐
    │                    OPERAÇÃO ECONÔMICA                                    │
    │ venda | serviço | devolução | cancelamento | ajuste | complemento       │
    └──────────────────────────────────┬───────────────────────────────────────┘
                                       │
                                       ▼
    ┌──────────────────────────────────────────────────────────────────────────┐
    │ 1. DOCUMENTO FISCAL E PROVENIÊNCIA                                      │
    │ emissor | destinatário | itens | valores | tributos | versão | XML      │
    └──────────────────────────────────┬───────────────────────────────────────┘
                                       │
                                       ▼
    ┌──────────────────────────────────────────────────────────────────────────┐
    │ 2. IDENTIDADE TRANSACIONAL                                               │
    │ documento_id | operação_id | pagamento_id | resource_id | correlação   │
    └──────────────────────────────────┬───────────────────────────────────────┘
                                       │
                                       ▼
    ┌──────────────────────────────────────────────────────────────────────────┐
    │ 3. GRAFO FISCAL E FINANCEIRO                                             │
    │ contribuinte | documento | item | obrigação | pagamento | PSP | estado  │
    └────────────────┬────────────────────────────────┬────────────────────────┘
                     │                                │
                     ▼                                ▼
    ┌─────────────────────────────────┐  ┌─────────────────────────────────────┐
    │ 4. MOTOR TRIBUTÁRIO             │  │ 5. MOTOR DETERMINÍSTICO             │
    │ base | alíquota | crédito       │  │ esquema | regras | permissões       │
    │ benefício | regime | período    │  │ integridade | temporalidade         │
    └────────────────┬────────────────┘  └──────────────────┬──────────────────┘
                     │                                      │
                     └──────────────────┬───────────────────┘
                                        ▼
    ┌──────────────────────────────────────────────────────────────────────────┐
    │ 6. ORDEM DE PAGAMENTO E SEPARAÇÃO                                        │
    │ valor total | parcela tributária | recebedor | instrução | vencimento   │
    └──────────────────────────────────┬───────────────────────────────────────┘
                                       │
                                       ▼
    ┌──────────────────────────────────────────────────────────────────────────┐
    │ 7. PSP E CAMADA DE INTEGRAÇÃO                                            │
    │ autenticação | API | idempotência | processamento | retorno | erro      │
    └──────────────────────────────────┬───────────────────────────────────────┘
                                       │
                         ┌─────────────┴─────────────┐
                         │                           │
                         ▼                           ▼
             ┌────────────────────────┐  ┌─────────────────────────────┐
             │ OPERAÇÃO REPROVADA     │  │ OPERAÇÃO ELEGÍVEL          │
             │ bloqueio + motivo      │  │ regra + valores + evidência│
             └────────────┬───────────┘  └──────────────┬──────────────┘
                          │                             │
                          └──────────────┬──────────────┘
                                         ▼
    ┌──────────────────────────────────────────────────────────────────────────┐
    │ 8. LIQUIDAÇÃO E CONCILIAÇÃO                                              │
    │ solicitado | separado | liquidado | devolvido | ajustado | divergente  │
    └──────────────────────────────────┬───────────────────────────────────────┘
                                       │
                                       ▼
    ┌──────────────────────────────────────────────────────────────────────────┐
    │ 9. CONTABILIDADE, TESOURARIA E AUDITORIA                                 │
    │ lançamento | caixa | obrigação | crédito | exceção | reconciliação      │
    └──────────────────────────────────┬───────────────────────────────────────┘
                                       │
                                       ▼
    ┌──────────────────────────────────────────────────────────────────────────┐
    │ 10. MONITORAMENTO E GOVERNANÇA                                           │
    │ disponibilidade | latência | duplicidade | fraude | versão | incidente │
    └──────────────────────────────────────────────────────────────────────────┘

A lousa mostra que o Split Payment não deve ser implementado como uma chamada isolada de API.

Ele precisa integrar:

* evento comercial;

* documento fiscal;

* identificador transacional;

* regra tributária;

* ordem de pagamento;

* PSP;

* liquidação;

* conciliação;

* contabilidade;

* auditoria.

O núcleo da infraestrutura é formado pelo '''grafo fiscal e financeiro''', pelo '''motor de regras''', pela '''identidade transacional''' e pela '''máquina de estados de conciliação'''.

== Como a infraestrutura torna possíveis os 12 pontos ==

=== 1. Fim do chamado “float fiscal” ===

'''Trecho relacionado: 01:45'''

O comentário utiliza “float fiscal” para representar o intervalo entre o recebimento financeiro e o cumprimento da obrigação tributária.

Uma segregação antecipada pode alterar:

* capital de giro;

* saldo disponível;

* projeção de caixa;

* calendário de pagamentos;

* necessidade de financiamento;

* tratamento de devoluções;

* tratamento de créditos;

* conciliação contábil.

A infraestrutura não pode assegurar ausência de lacunas de liquidez. Ela pode tornar o impacto mensurável por meio de estados e projeções.

    operação_prevista
          ↓
    valor_bruto
          ↓
    valor_tributário_estimado
          ↓
    valor_líquido_estimado
          ↓
    separação_executada
          ↓
    liquidação_confirmada
          ↓
    divergência_apurada

O sistema deve comparar valores previstos e realizados.

'''Resultado arquitetural:''' o efeito de caixa deixa de ser inferido apenas após o fechamento e passa a ser monitorado por operação, regra, período e estado.

=== 2. Arquitetura como prioridade ===

'''Trecho relacionado: 04:32'''

Mudanças na mecânica de pagamento afetam integrações, tesouraria, conciliação, ERP, emissão fiscal, contabilidade e atendimento.

A arquitetura precisa mapear:

* sistemas de origem;

* contratos de dados;

* dependências;

* identificadores;

* regras vigentes;

* eventos assíncronos;

* exceções;

* políticas de repetição;

* contingência;

* responsabilidade por cada etapa.

O grafo oferece precisão estrutural, mas não “precisão absoluta”. A qualidade depende das fontes, regras, integrações e atualizações.

'''Resultado arquitetural:''' decisões de integração passam a considerar o fluxo completo, em vez de tratar a mudança apenas como negociação de taxa ou configuração do PSP.

=== 3. Plataforma pública como hub ===

'''Trecho relacionado: 05:45'''

O papel exato de cada plataforma pública deve seguir a regulamentação e a documentação oficial.

Arquiteturalmente, um hub pode exercer funções como:

* receber consultas;

* validar identidade;

* retornar parâmetros;

* correlacionar eventos;

* registrar estados;

* distribuir notificações;

* informar erros;

* disponibilizar dados para conciliação.

O sistema do contribuinte não deve presumir que o hub calculará, validará ou corrigirá toda informação. Também não deve presumir que toda responsabilidade será transferida ao contribuinte.

A matriz de responsabilidade precisa ser explícita:

    contribuinte
    ERP
    emissor fiscal
    PSP
    instituição financeira
    plataforma pública
    responsável contábil
    autoridade tributária

'''Resultado arquitetural:''' o hub é integrado como participante com funções definidas, sem ser tratado como fonte universal de toda verdade fiscal.

=== 4. Natureza contábil e fiscal do tributo ===

'''Trecho relacionado: 04:09'''

O comentário afirma que o imposto nunca foi receita. A classificação contábil e fiscal deve seguir as normas aplicáveis à operação e à entidade.

A arquitetura separa:

    valor da operação
    valor recebido
    valor tributário
    valor separado
    valor creditável
    valor liquidado
    valor devolvido
    ajuste
    saldo contábil

A segregação técnica não substitui a interpretação contábil ou jurídica. Ela permite representar cada parcela sem misturá-la ao fluxo financeiro total.

A conformidade por código pode automatizar regras, mas as regras precisam possuir:

* fonte normativa;

* versão;

* início de vigência;

* fim de vigência;

* jurisdição;

* regime aplicável;

* responsável pela implementação;

* testes;

* aprovação.

'''Resultado arquitetural:''' valores fiscais e financeiros são representados separadamente, com regras versionadas e histórico auditável.

=== 5. Responsabilidade do PSP ===

'''Trecho relacionado: 03:23'''

O PSP torna-se um componente crítico sempre que participa da recepção, transmissão, separação, liquidação ou confirmação de uma operação.

O grafo pode representar:

    PSP
    ├── presta_serviço → processamento
    ├── atende → meio_de_pagamento
    ├── utiliza → endpoint
    ├── recebeu → instrução
    ├── produziu → evento
    ├── possui → SLA
    └── responde_por → etapa_definida

A integração precisa monitorar:

* disponibilidade;

* latência;

* autenticação;

* idempotência;

* duplicidade;

* ordenação de eventos;

* consistência dos retornos;

* tratamento de erro;

* capacidade de reprocessamento;

* conciliação.

'''Resultado arquitetural:''' o PSP deixa de ser uma dependência opaca e passa a ser um nó com funções, evidências e níveis de serviço explícitos.

=== 6. Resource ID e identidade transacional ===

'''Trecho relacionado: 03:45'''

Um identificador de recurso pode relacionar eventos distribuídos entre sistemas.

Ele deve possuir:

* unicidade dentro do escopo definido;

* formato estável;

* validação;

* não reutilização indevida;

* relação com IDs externos;

* registro de criação;

* proteção contra colisões;

* política de retenção;

* capacidade de correlação.

Exemplo:

    operação_id → representa → operação_comercial
    nota_id → documenta → operação_comercial
    pagamento_id → liquida → operação_comercial
    resource_id → correlaciona → nota_id
    resource_id → correlaciona → pagamento_id
    evento_psp_id → pertence_a → resource_id

Um único identificador não substitui todos os IDs de domínio. Ele funciona como chave de correlação entre objetos que continuam possuindo identidades próprias.

'''Resultado arquitetural:''' nota, pagamento, separação e liquidação podem ser conciliados sem perder a identidade individual de cada objeto.

=== 7. Campos do documento fiscal ===

'''Trecho relacionado: 06:40'''

O XML do documento fiscal pode atuar como uma fonte importante da operação declarada, conforme o esquema oficial aplicável.

Ele não deve ser tratado como única fonte de toda realidade econômica ou financeira.

A infraestrutura pode extrair:

* emissor;

* destinatário;

* itens;

* valores;

* códigos fiscais;

* tributos;

* referências;

* datas;

* versão do leiaute;

* assinatura;

* autorização;

* eventos de cancelamento ou correção.

O pipeline pode operar assim:

    XML recebido
         ↓
    assinatura e estrutura verificadas
         ↓
    esquema identificado
         ↓
    campos normalizados
         ↓
    entidades vinculadas
         ↓
    regras aplicadas
         ↓
    pagamento correlacionado
         ↓
    conciliação

'''Resultado arquitetural:''' o documento fiscal fornece proveniência estruturada para a operação, enquanto pagamento e liquidação permanecem eventos independentes e relacionados.

=== 8. Período de testes e maturação ===

'''Trecho relacionado: 07:13'''

O comentário apresenta 2026 como período de stress test. Essa classificação precisa ser confirmada em fontes oficiais antes de orientar implementação.

Independentemente do calendário, uma mudança desse porte exige:

* ambiente de homologação;

* dados sintéticos;

* testes de volume;

* testes de falha;

* testes de duplicidade;

* testes de latência;

* cenários de devolução;

* cancelamentos;

* indisponibilidade do hub;

* indisponibilidade do PSP;

* mudança de regra;

* conciliação retroativa;

* reversão segura.

Estados de preparação:

    NÃO_INICIADO
    MAPEADO
    PROTOTIPADO
    HOMOLOGADO
    PILOTO
    PRODUÇÃO_CONTROLADA
    PRODUÇÃO
    CONTINGÊNCIA

'''Resultado arquitetural:''' a organização acompanha sua maturidade por evidências, sem depender de uma declaração genérica de que está pronta.

=== 9. Independência de regime e parametrização ===

'''Trecho relacionado: 06:21'''

A infraestrutura deve separar o mecanismo de processamento dos parâmetros tributários.

O motor pode receber:

    operação
    contribuinte
    regime
    período
    item
    local
    base
    benefício
    alíquota
    crédito
    exceção

Essa separação permite atualizar parâmetros sem reescrever integralmente o sistema.

Entretanto, o design não é totalmente independente de regime. Regimes e tratamentos diferenciados podem alterar dados obrigatórios, cálculos, créditos, obrigações e exceções.

'''Resultado arquitetural:''' regras tributárias são parametrizadas e versionadas, mantendo explícita a influência do regime sobre o resultado.

=== 10. Faseamento da implantação ===

'''Trecho relacionado: 08:13'''

A implantação gradual pode reduzir risco ao limitar inicialmente meios, participantes, operações ou cenários.

A ordem específica entre Pix, boleto, cartões ou outros instrumentos deve seguir o cronograma oficial.

A arquitetura de faseamento pode utilizar:

    FASE 0 → simulação
    FASE 1 → ambiente de homologação
    FASE 2 → operações selecionadas
    FASE 3 → meios de pagamento definidos
    FASE 4 → ampliação de participantes
    FASE 5 → cobertura operacional
    FASE 6 → otimização e auditoria contínua

Cada fase precisa de:

* critérios de entrada;

* critérios de saída;

* volume limite;

* responsáveis;

* métricas;

* contingência;

* autorização;

* plano de reversão.

'''Resultado arquitetural:''' a implantação cresce por estados verificáveis, sem expor todo o ecossistema à mudança de uma só vez.

=== 11. Integração via API ===

'''Trecho relacionado: 05:26'''

Swagger ou OpenAPI pode documentar contratos de API, mas não elimina erro humano ou risco operacional.

Uma integração segura exige:

* autenticação;

* autorização;

* criptografia;

* validação de esquema;

* idempotência;

* controle de versão;

* limite de requisições;

* timeout;

* repetição controlada;

* circuit breaker;

* logging;

* proteção de segredos;

* observabilidade;

* tratamento de indisponibilidade.

Fluxo:

    chamada preparada
          ↓
    esquema validado
          ↓
    credencial verificada
          ↓
    identificador de idempotência
          ↓
    requisição enviada
          ↓
    resposta classificada
          ├── sucesso
          ├── pendente
          ├── rejeitada
          ├── repetível
          └── erro definitivo
          ↓
    evento registrado
          ↓
    conciliação

'''Resultado arquitetural:''' a API reduz tarefas manuais, mas sua segurança depende de contratos, estados, controles e tratamento determinístico de erros.

=== 12. Sobrevivência e interoperabilidade do stack ===

'''Trecho relacionado: 10:01'''

PSPs e sistemas que não acompanharem padrões obrigatórios podem enfrentar perda de interoperabilidade, aumento de custo ou restrição de participação.

Isso não significa automaticamente obsolescência completa. A consequência dependerá das regras, do mercado, da capacidade de adaptação e do papel desempenhado.

A preparação pode ser avaliada por:

* suporte aos identificadores exigidos;

* compatibilidade com esquemas;

* capacidade de versionamento;

* reconciliação automatizada;

* exportação de eventos;

* observabilidade;

* contingência;

* documentação;

* portabilidade;

* conformidade demonstrável.

'''Resultado arquitetural:''' a continuidade do stack passa a depender de integração verificável e capacidade de evolução, não apenas da existência de uma API.

== I.N.D.I.A. como camada de interoperabilidade ==

No contexto desta análise, a camada '''I.N.D.I.A.''' é apresentada como mecanismo de padronização semântica entre sistemas fiscais, financeiros e operacionais.

Sua função pode incluir:

* identificar entidades;

* normalizar propriedades;

* mapear esquemas;

* preservar proveniência;

* controlar versões;

* validar restrições;

* relacionar eventos;

* detectar divergências;

* permitir consultas;

* apoiar auditoria.

Estrutura conceitual:

    operação
    ├── possui_documento_fiscal
    ├── possui_pagamento
    ├── possui_obrigação
    ├── processada_por_PSP
    ├── possui_regra_aplicada
    ├── possui_separação
    ├── possui_liquidação
    ├── possui_conciliação
    └── possui_estado

A camada semântica não substitui a infraestrutura oficial. Ela organiza o estado interno do contribuinte e suas relações com sistemas externos.

== Máquina de estados do Split Payment ==

    OPERAÇÃO CRIADA
         │
         ▼
    DOCUMENTO FISCAL EMITIDO
         │
         ├──────────────► REJEITADO
         ├──────────────► CANCELADO
         │
         ▼
    PAGAMENTO INICIADO
         │
         ├──────────────► EXPIRADO
         ├──────────────► RECUSADO
         │
         ▼
    REGRA TRIBUTÁRIA APLICADA
         │
         ├──────────────► DIVERGENTE
         ├──────────────► REVISÃO NECESSÁRIA
         │
         ▼
    SEPARAÇÃO SOLICITADA
         │
         ├──────────────► FALHA TEMPORÁRIA
         ├──────────────► FALHA DEFINITIVA
         │
         ▼
    SEPARAÇÃO CONFIRMADA
         │
         ▼
    LIQUIDAÇÃO
         │
         ├──────────────► PARCIAL
         ├──────────────► DEVOLUÇÃO
         ├──────────────► AJUSTE
         │
         ▼
    CONCILIAÇÃO
         │
         ├──────────────► DIVERGÊNCIA
         │
         ▼
    CONTABILIZADO
         │
         ▼
    AUDITADO
         │
         ├──────────────► RETIFICADO
         └──────────────► ENCERRADO

Nenhuma atualização deve apagar silenciosamente o estado anterior.

== Conciliação determinística ==

A conciliação compara pelo menos quatro valores:

    valor declarado
    valor solicitado
    valor separado
    valor liquidado

Também pode considerar:

* valor devolvido;

* valor ajustado;

* tarifa;

* desconto;

* crédito;

* diferença cambial, quando aplicável;

* arredondamento;

* chargeback;

* cancelamento;

* evento posterior.

Uma divergência deve registrar:

    divergencia_id
    operação_id
    documento_id
    pagamento_id
    valor_esperado
    valor_observado
    diferença
    regra_aplicada
    origem
    responsável
    estado
    resolução
    instante

'''Resultado arquitetural:''' diferenças deixam de ser corrigidas apenas por intervenção manual sem histórico e tornam-se objetos rastreáveis.

== Soberania fiscal e de dados ==

Soberania fiscal não significa que o contribuinte define livremente a obrigação tributária.

Neste artigo, significa capacidade de:

* manter cópia estruturada dos próprios eventos;

* conhecer as regras utilizadas;

* reconciliar valores;

* detectar divergências;

* exportar dados;

* trocar de fornecedor;

* preservar histórico;

* controlar acessos;

* demonstrar evidências;

* contestar erros pelos canais aplicáveis.

A organização não deve depender exclusivamente do painel de um PSP para compreender seu próprio fluxo.

'''Resultado arquitetural:''' o contribuinte preserva capacidade operacional e probatória sem substituir a autoridade dos órgãos competentes.

== GraphRAG fiscal e financeiro ==

O GraphRAG pode responder perguntas internas como:

    Qual operação originou esta liquidação?
    Qual regra estava vigente?
    Qual PSP processou o pagamento?
    Existe divergência?
    O documento foi cancelado?
    Qual versão do esquema foi utilizada?
    Qual evento ainda está pendente?
    Qual valor foi devolvido?
    Quem aprovou o ajuste?

Fluxo:

# recebe a pergunta;

# identifica contribuinte, operação e período;

# verifica autorização;

# consulta o grafo;

# recupera eventos e versões;

# verifica proveniência;

# executa regras;

# identifica divergências;

# monta contexto mínimo;

# gera explicação;

# cita os registros internos;

# registra a consulta.

A IA não deve calcular ou afirmar obrigação tributária sem consultar regras autorizadas e vigentes.

== Proveniência e identidade persistente ==

O registro que originou esta página utiliza:

    ID do vídeo:
    35pEhb_BzZI

    URN:
    urn:determinar.ia.br:youtube:a-api-do-governo-que-vai-mudar-todo-sistema-de-pagamento-split-payment-explicado-pra-dev:35pEhb_BzZI

    CURIE:
    det:youtube:a-api-do-governo-que-vai-mudar-todo-sistema-de-pagamento-split-payment-explicado-pra-dev:35pEhb_BzZI

    Token canário:
    CAN:35pEhb_BzZI:711946ca

    ID do comentário:
    UgydiEAPlRajrFDjgUt4AaABAg

O momento técnico registrado pelo ingestor é:

    2026-08-30T14:57:13.021Z

Esse registro não confirma a vigência de cronogramas, especificações de API ou interpretações tributárias mencionadas na fonte.

Os estados devem permanecer separados:

    extraido_em
    normalizado_em
    verificado_tecnicamente_em
    verificado_em_fonte_oficial
    revisado_por_especialista
    estado_de_publicacao

== Papel do wikivendas.com.br e da determinar.ia.br ==

; '''wikivendas.com.br'''

: Atua na captura das necessidades de contribuintes, PSPs, integradores, contadores e desenvolvedores, além da qualificação das perguntas e checagens humanas iniciais.

; '''determinar.ia.br'''

: Atua na criação de identidade persistente, normalização semântica, modelagem de ontologias, validação estrutural, representação em grafo e disponibilização para consumo autorizado de máquina.

Fluxo:

    DÚVIDA OPERACIONAL
           ↓
    PERGUNTA QUALIFICADA
           ↓
    ENTIDADES IDENTIFICADAS
           ↓
    FONTE OFICIAL LOCALIZADA
           ↓
    REGRA E VIGÊNCIA MODELADAS
           ↓
    VALIDAÇÃO HUMANA
           ↓
    PUBLICAÇÃO NO GRAFO
           ↓
    CONSULTA E MONITORAMENTO

== Matriz de controles ==

{| class="wikitable sortable"
!Ponto
!Objeto principal
!Controle determinístico
!Responsável
!Evidência preservada
|-
|Liquidez
|Fluxo de caixa
|Comparação previsto × realizado
|Tesouraria
|Valores e instantes
|-
|Arquitetura
|Dependências
|Contratos e estados
|TI
|Versões e integrações
|-
|Hub público
|Serviço externo
|Matriz de responsabilidade
|Partes competentes
|Consultas e retornos
|-
|Natureza do tributo
|Classificação
|Regras versionadas
|Fiscal e contábil
|Fonte e vigência
|-
|PSP
|Processamento
|SLA e idempotência
|PSP e contratante
|Eventos e falhas
|-
|Resource ID
|Correlação
|Unicidade e validação
|Arquitetura
|Relações entre IDs
|-
|Documento fiscal
|XML
|Esquema e assinatura
|Emissor
|Documento e eventos
|-
|Preparação
|Maturidade
|Critérios por fase
|Programa responsável
|Testes e resultados
|-
|Regime
|Parâmetro tributário
|Temporalidade e versão
|Área fiscal
|Regra aplicada
|-
|Faseamento
|Implantação
|Portas de entrada e saída
|Governança
|Aprovações e métricas
|-
|API
|Integração
|Autenticação e tratamento de erros
|Equipe técnica
|Chamadas e respostas
|-
|Interoperabilidade
|Stack
|Padrões e exportação
|PSP e contribuinte
|Compatibilidade
|}

== Indicadores de governança ==

* percentual de operações com identificador correlacionado;

* percentual de pagamentos ligados ao documento fiscal;

* percentual de regras com fonte e vigência;

* taxa de duplicidade;

* taxa de falha por PSP;

* latência de consulta;

* latência de liquidação;

* quantidade de divergências;

* tempo médio de conciliação;

* percentual de reprocessamentos idempotentes;

* disponibilidade das integrações;

* percentual de eventos fora de ordem;

* quantidade de ajustes manuais;

* percentual de ajustes com justificativa;

* impacto no capital de giro;

* percentual de operações reconciliadas;

* taxa de devoluções corretamente vinculadas;

* percentual de versões de API suportadas;

* tempo para incorporar mudança normativa;

* percentual de consultas com proveniência completa.

== Perguntas frequentes ==

=== O Split Payment é apenas uma API? ===

Não. Ele envolve documentos fiscais, regras tributárias, meios de pagamento, participantes financeiros, liquidação, conciliação, contabilidade e auditoria.

=== O imposto é calculado pelo PSP? ===

A função precisa ser determinada pela regulamentação e pela documentação aplicável. A arquitetura não deve presumir responsabilidades não confirmadas.

=== O XML da nota é a única fonte da operação? ===

Não. Ele representa o documento fiscal. Pagamento, liquidação, devolução e ajuste possuem eventos próprios.

=== Swagger elimina erros? ===

Não. Ele documenta contratos de API. Erros ainda podem ocorrer em implementação, dados, autenticação, versionamento e operação.

=== O Resource ID substitui todos os identificadores? ===

Não. Ele pode correlacionar objetos, mas cada domínio deve preservar seus próprios identificadores.

=== Um grafo calcula tributos automaticamente? ===

O grafo organiza fatos e relações. O cálculo depende de regras vigentes, parâmetros, fontes e responsabilidade técnica.

=== A arquitetura é independente do regime tributário? ===

O mecanismo pode ser parametrizado, mas o regime pode alterar regras, dados, créditos e tratamentos.

=== Split Payment elimina a necessidade de conciliação? ===

Não. Aumenta a importância de conciliar documento, pagamento, separação, liquidação, devolução e ajustes.

=== O PSP passa a controlar os dados do contribuinte? ===

O contribuinte deve preservar acesso, exportação, histórico e capacidade própria de conciliação, conforme contratos e regras aplicáveis.

=== A plataforma pública é a única fonte da verdade? ===

Não necessariamente. O fluxo é distribuído entre documentos, sistemas do contribuinte, PSPs, instituições e serviços públicos.

=== O GraphRAG pode responder dúvidas fiscais? ===

Pode recuperar regras e eventos autorizados, mas não substitui orientação contábil ou jurídica especializada.

=== Como tratar indisponibilidade da API? ===

Com estados de contingência, filas, idempotência, repetição controlada, monitoramento e posterior conciliação, conforme as regras oficiais.

=== Como tratar devoluções? ===

A devolução deve ser relacionada ao pagamento, documento, separação original, regra aplicável e eventos de ajuste.

=== O ano de 2026 é oficialmente um stress test? ===

Essa formulação pertence ao comentário analisado e precisa de confirmação em documentação oficial antes de orientar um projeto.

=== O que é soberania fiscal neste artigo? ===

É a capacidade de compreender, preservar, reconciliar, exportar e auditar os próprios eventos fiscais e financeiros.

=== I.N.D.I.A. substitui sistemas oficiais? ===

Não. Atua como camada semântica interna ou interoperável, sujeita aos contratos e padrões oficiais.

== Cuidados editoriais ==

* o artigo não confirma cronogramas oficiais;

* “fim do float fiscal” é uma formulação analítica;

* a plataforma pública não é presumida como mero orquestrador;

* o PSP não recebe responsabilidades além das definidas oficialmente;

* o XML não representa sozinho toda a realidade da operação;

* Swagger não elimina erro humano;

* grafos não oferecem precisão absoluta;

* infraestrutura como código não substitui validação jurídica ou contábil;

* faseamento por meio de pagamento precisa de confirmação oficial;

* soberania de dados não permite ignorar obrigações legais;

* GraphRAG não substitui especialistas;

* o artigo descreve uma arquitetura conceitual, não uma especificação oficial.

== Escopo ==

=== Incluído no escopo ===

* arquitetura de Split Payment;

* documentos fiscais;

* pagamentos;

* PSPs;

* identidade transacional;

* Resource ID;

* APIs;

* idempotência;

* regras tributárias versionadas;

* grafos fiscais e financeiros;

* conciliação;

* liquidação;

* devoluções e ajustes;

* soberania de dados;

* I.N.D.I.A.;

* GraphRAG;

* auditoria;

* monitoramento;

* testes;

* faseamento;

* interoperabilidade;

* proveniência;

* integração entre wikivendas.com.br e determinar.ia.br.

=== Fora do escopo ===

* aconselhamento tributário;

* parecer jurídico ou contábil;

* confirmação de cronograma oficial;

* especificação oficial de API;

* definição de alíquotas;

* cálculo de tributos reais;

* interpretação definitiva da Reforma Tributária;

* definição das responsabilidades legais do PSP;

* garantia de liquidez;

* garantia de ausência de erro;

* promessa de precisão absoluta;

* homologação de fornecedor;

* certificação de conformidade;

* substituição da documentação governamental;

* substituição de profissionais especializados.

== Limites e salvaguardas ==

A arquitetura precisa reconhecer que:

* normas podem mudar;

* documentação pode ser atualizada;

* APIs podem alterar versões;

* regras podem ser implementadas incorretamente;

* identificadores podem ser associados de forma errada;

* eventos podem chegar fora de ordem;

* PSPs podem ficar indisponíveis;

* documentos podem ser cancelados;

* pagamentos podem ser parciais;

* devoluções podem ocorrer depois da liquidação;

* conciliações podem exigir análise humana;

* grafos podem conter dados incorretos;

* auditoria pode expor informações sensíveis;

* dependência de um único fornecedor cria risco;

* contingência precisa ser testada;

* controles fiscais e contábeis precisam de revisão especializada.

Por isso, regras, integrações, esquemas, ontologias e máquinas de estado devem possuir versionamento, testes, aprovação, monitoramento e reversibilidade.

== Conclusão ==

O Split Payment não deve ser tratado apenas como uma nova chamada de API. Ele conecta o evento econômico, o documento fiscal, a regra tributária, o pagamento, o PSP, a liquidação, a contabilidade e a auditoria.

A operação nasce. O documento declara. O identificador conecta. A regra calcula. O PSP processa. A separação distribui. A conciliação verifica. O grafo preserva. A auditoria reconstrói.

A contribuição da IA Determinística está em manter essas relações visíveis e verificáveis.

Quando cada evento possui identidade, proveniência, estado, versão e responsável, a organização reduz sua dependência de planilhas isoladas, interpretações implícitas e conciliações sem histórico.

== Fonte analisada ==

* '''Vídeo:''' 🚨 A API DO GOVERNO QUE VAI MUDAR TODO SISTEMA DE PAGAMENTO | SPLIT PAYMENT EXPLICADO PRA DEV

* '''Canal:''' mano deyvin

* '''ID do vídeo:''' 35pEhb_BzZI

* '''URL:''' https://www.youtube.com/watch?v=35pEhb_BzZI

* '''Comentário de origem:''' https://www.youtube.com/watch?v=35pEhb_BzZI&lc=UgydiEAPlRajrFDjgUt4AaABAg&pp=0gcJCSIANpG00pGi

* '''Início referenciado:''' https://www.youtube.com/watch?v=35pEhb_BzZI&t=105s

* '''Autor do comentário:''' @paulo-leads

* '''Estado da captura:''' extraído do DOM, pendente de verificação humana

* '''Data técnica registrada:''' 30 de agosto de 2026, 14:57:13 UTC

[[Category:IA determinística]]
[[Category:Split Payment]]
[[Category:Reforma Tributária]]
[[Category:Sistemas de pagamento]]
[[Category:Tecnologia financeira]]
[[Category:Governança de dados]]
[[Category:Governança fiscal]]
[[Category:Grafos de conhecimento]]
[[Category:GraphRAG]]
[[Category:Engenharia de ontologias]]
[[Category:APIs]]
[[Category:Conciliação financeira]]
[[Category:Documentos fiscais eletrônicos]]
[[Category:Proveniência de dados]]
[[Category:Interoperabilidade]]
[[Category:Infraestrutura de conhecimento]]