diff --git a/portal_api/planos_saude/CHANGELOG.md b/portal_api/planos_saude/CHANGELOG.md
index 76e8477..f04a12f 100644
--- a/portal_api/planos_saude/CHANGELOG.md
+++ b/portal_api/planos_saude/CHANGELOG.md
@@ -250,3 +250,7 @@ Usuário reportou (competência 09/2026, empresa Questor 604, arquivo "COP GERAL
 Usuário reportou, testando a correção acima pela tela: depois de editar Valor/Valor Empresa numa linha, os contadores do topo ("com valor lançado"/"em auditoria") e a aba Alterações continuavam mostrando o estado de antes da edição, só atualizando de verdade depois de sair da importação e reabri-la. Causa: o handler de `change` das células (`importacao-plano-saude.js`) já mandava o PATCH pro servidor, mas nunca atualizava `importacaoAtual` nem chamava `renderTabs()` depois — diferente de toda outra ação da revisão (adicionar/remover linha, vincular pessoa, reverter alteração), que já recarrega a importação inteira e re-renderiza. Corrigido replicando o mesmo padrão: depois do PATCH ter sucesso, `importacaoAtual = await pidFetchImportacaoPlanoSaude(...)` seguido de `renderTabs()`.
 
 Aproveitando a mesma conversa, usuário pediu que as células de Valor/Valor Empresa aceitem uma expressão de soma/subtração digitada direto (ex.: `"15,30-15"` pra abater R$15 do valor, sem precisar calcular fora e digitar o resultado pronto). Implementado client-side: `pidAvaliaExpressaoValorMonetario()` reconhece números em formato BR (vírgula decimal, ponto de milhar opcional) separados por `+`/`-` e, se o texto digitado for uma expressão válida (sobra zero caractere não reconhecido), substitui o campo pelo resultado já calculado antes do PATCH — um valor negativo isolado (ex.: `"-15,30"`) continua sendo só um número, não uma expressão (só conta como expressão se houver operador depois do primeiro caractere). O backend não teve nenhuma mudança — `valor`/`valor_empresa` continuam sendo `CharField` sem validação de formato, então já aceitava (e continua aceitando) qualquer string; a expressão nunca chega até lá, só o resultado.
+
+### Bug real — código de cadastro da Dental Uni Odonto estava errado (1723 → 4723)
+
+Usuário avisou que o código de cadastro da operadora "Dental Uni Odonto" no Questor está registrado errado desde a Rodada 49 (`1723`); o código correto é `4723` — confirmado batendo com os arquivos reais de planilha padrão já salvos no sistema (nomes de arquivo trazem `OPER_4723_DENTAL_UNI...`). Corrigido `OPERADORAS["dental_uni_odonto_mensalidade"]["codigo_operadora"]` em `pipeline.py`; o label de exibição (`"4723 - Dental Uni Odonto"`) é derivado desse campo em todo lugar que usa `label_operadora()`/`lista_operadoras()` (combobox de operadora, mensagens de erro, `nome_operadora` de importação), então a correção já se propaga sozinha sem precisar tocar em mais nada. Registros já persistidos de importações antigas (`ImportacaoPlanoSaude.nome_operadora`, texto congelado no momento da criação) não são retroativamente corrigidos.
diff --git a/portal_api/planos_saude/pipeline.py b/portal_api/planos_saude/pipeline.py
index 0ff6f4d..e3cfa6d 100644
--- a/portal_api/planos_saude/pipeline.py
+++ b/portal_api/planos_saude/pipeline.py
@@ -46,7 +46,7 @@ OPERADORAS = {
         "parser": ItamedSaude,
     },
     "dental_uni_odonto_mensalidade": {
-        "codigo_operadora": "1723",
+        "codigo_operadora": "4723",
         "nome": "Dental Uni Odonto",
         "parser": DentalUniOdontoMensalidade,
     },