Specialist ERPsERP Platform

TOTVS Protheus + private AI

AI for TOTVS Protheus: grounded answers inside your own data boundary

Short answer

Adding AI to TOTVS Protheus means reading through its Framework REST API or a database replica, mapping AdvPL customizations and Brazil's fiscal compliance stack (SPED, NF-e, ICMS) into a documented semantic layer, and grounding a model on that data under LGPD-aware controls. TOTVS is Latin America's largest ERP vendor, and most of its manufacturing and distribution customers carry years of bespoke AdvPL code that any AI layer has to work with rather than around.

ERP: TOTVS Protheus, TOTVS Datasul, TOTVS RM
Industries: Manufacturing, Distribution, Agribusiness, Retail
Written for: CIO

Discuss your TOTVS Protheus environment See use cases

TOTVS is the dominant ERP vendor across Brazil and much of Latin America, and Protheus in particular runs a huge share of mid-market and large manufacturers and distributors in the region. Like most long-lived ERPs, that install base carries years of customization written in AdvPL (Advanced Protheus Language), TOTVS's own 4GL, and that customization is exactly what determines whether an AI layer works or produces confidently wrong answers.

Brazil's fiscal compliance stack adds a layer most other ERP regions do not deal with: SPED digital bookkeeping, NF-e electronic invoicing, and state-by-state ICMS variation all live inside or alongside Protheus, and finance teams spend real time reconciling exceptions that a grounded model can help triage, without it ever being treated as authoritative tax or legal advice.

Because Protheus and Datasul customers include manufacturers in aerospace-adjacent, defense-adjacent, and other export-sensitive supply chains, as well as companies simply unwilling to route ERP data through a shared multi-tenant AI product, keeping the model inside the customer's own infrastructure is usually a hard requirement, not a preference.

This page covers what actually needs to be built: the connector into Protheus through its Framework REST API or a database replica, a semantic layer over AdvPL customizations and fiscal data, deployment options that respect LGPD, and the questions worth asking before starting.

What usually gets in the way

The problems we hear most from cio teams running TOTVS Protheus.

AdvPL expertise is scarce and expensive

Most non-standard reporting or process changes require an AdvPL developer, and finding one with both the language skill and business context is harder than it should be.

Fiscal reporting is brittle and critical

SPED, NF-e, and ICMS-related reports are built as custom AdvPL routines that are business-critical and rarely have spare documentation when the original author moves on.

Multi-branch tax complexity slows finance

State-by-state ICMS variation means finance teams spend real time investigating tax exceptions across branches rather than getting a direct explanation.

LGPD adds friction to any new tool

Any system touching customer, employee, or supplier personal data has to clear an LGPD review, which slows adoption of off-the-shelf cloud AI products that were not designed with that review in mind.

TOTVS's own AI features are multi-tenant cloud

TOTVS's native AI and data platform capabilities run in TOTVS's own cloud, which does not fit customers who need the model and data to stay inside their own infrastructure.

Where AI earns its place in TOTVS Protheus

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Natural-language query over sales, inventory, and fiscal data

Let finance and operations staff ask direct questions about orders, stock, and tax-relevant transactions without a new AdvPL report for every variant.

Touches: TOTVS Framework REST API, or a read-only database replica covering AdvPL-customized tables

Outcome: Cuts routine report requests to genuinely novel questions that still need AdvPL work.

Multi-state ICMS exception explanation

Explain why a specific transaction's ICMS calculation differs from expectation, referencing the relevant state rule and the transaction's actual tax configuration, for a finance team member to verify.

Touches: Fiscal/tax tables, NF-e records, branch and state tax configuration

Outcome: Shortens the time finance spends investigating routine tax exceptions before escalating genuine issues.

Purchase order and vendor follow-up automation

Draft vendor follow-up communications for late or at-risk POs, referencing line-level detail and vendor history.

Touches: Purchasing module records, vendor master data

Outcome: Turns a manual PO-chase task into a reviewed, ready-to-send draft list.

Quality and NCR documentation drafting

Draft non-conformance report narratives from inspection and rejection data already captured in Protheus, for a quality engineer to review.

Touches: Quality/inspection tables, item and lot records

Outcome: Shortens time to a reviewable NCR draft after a rejection is logged.

MRP and production exception triage

Summarize and rank the day's material shortages and late orders so planners act on the highest-impact issues first.

Touches: MRP/planning tables, work order and purchase order records

Outcome: Reduces time planners spend scanning raw planning output before acting.

AdvPL customization documentation assistant

Let IT staff ask what a specific AdvPL routine does and where its data comes from, grounded in source code, change logs, and existing documentation.

Touches: AdvPL source code, change logs, internal customization documentation

Outcome: Cuts the time a new developer needs to become productive on inherited customizations.

SPED and NF-e exception triage support

Flag and summarize likely causes of SPED or NF-e transmission exceptions for a finance or fiscal team member to review and resolve, without generating filings itself.

Touches: SPED digital bookkeeping records, NF-e transmission logs

Outcome: Reduces time spent identifying the root cause of routine fiscal transmission exceptions.

Reference architecture

A TOTVS AI deployment reads through the Framework REST API or a database replica, adds a semantic layer over AdvPL customizations and Brazil's fiscal data stack, serves a model on infrastructure the customer controls, and enforces Protheus's own security model on every query.

1
ERP connectors
Read access via the TOTVS Framework REST API for supported objects, or a read-only replica of the underlying SQL Server, Oracle, or PostgreSQL database for AdvPL-customized data.
2
Data and semantic layer
A documented mapping of AdvPL-customized fields, custom routines, and fiscal data structures (NF-e, SPED, ICMS configuration) into consistent business terms.
3
Model serving
Open-weight models served with vLLM or Ollama on customer-owned GPUs or a private cloud tenancy, sized to actual concurrency needs.
4
Retrieval and agents
Retrieval-augmented generation over the semantic layer plus structured query tools, with any write-back routed through a human approval step.
5
Governance and audit
Query-level logging mapped to Protheus's own user and permission groups, keeping fiscal and production records themselves untouched by the AI layer.

Integration notes for your ERP team

The TOTVS Framework REST API covers many standard objects; AdvPL-customized fields and tables often require a read-only database replica to reach reliably.
AdvPL routines and custom fields need to be inventoried and documented before the semantic layer is built; assuming a stock Protheus schema will produce confidently wrong answers.
NF-e XML documents and SPED extracts are a distinct, document-shaped data source worth treating separately from transactional database tables in the retrieval design.
State-by-state ICMS configuration should be modeled explicitly in the semantic layer, since it is one of the most common sources of finance-team questions.
Multi-branch or multi-company Protheus environments need schema reconciliation before cross-branch questions can be answered reliably.
Any write-back to Protheus should go through AdvPL-validated API paths, never a raw database write, to preserve the same business-rule enforcement the ERP already applies.
TOTVS Fluig, where used for workflow and portal functions, is a reasonable trigger point for downstream actions once a person approves an AI-suggested step.

Deployment options

Air-gapped on-prem

Manufacturers in export-sensitive or IP-sensitive supply chains needing data to stay entirely inside their own network

Model, retrieval layer, and connector run inside the customer network with no outbound path for ERP or fiscal data.

Private or sovereign cloud

TOTVS customers without in-house GPU capacity who still need dedicated, single-tenant, Brazil-resident infrastructure

Runs in a customer-controlled cloud tenancy rather than TOTVS's own multi-tenant AI platform or a generic public AI service.

Hybrid

Multi-branch TOTVS estates with mixed sensitivity across sites or business units

Sensitive branches run on-prem while others use private cloud, unified by a shared semantic layer and governance model.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

LGPD (Lei Geral de Protecao de Dados)

Keep personal data inside the same access controls and, where required, the same jurisdiction as the source Protheus environment, with a clear lawful basis and minimal default retention for anything the AI layer touches.

ISO 27001

Fit the connector, storage, and logging layers inside an existing ISMS scope rather than standing up a parallel, ungoverned system.

SPED and fiscal audit-trail integrity

Keep the AI layer strictly read-grounded and fully logged so it never alters the original fiscal records that SPED and tax audits rely on.

Data residency (ANPD expectations)

For customers with Brazil-resident data requirements, keep model serving and storage inside Brazil or a jurisdiction acceptable under the customer's own data governance policy.

Where Netray fits

Custom build

TOTVS is not part of Netray's packaged connector set today, so integration is scoped as a custom engagement against the Framework REST API and, where needed, a database replica, following the same connector-plus-semantic-layer pattern used for other specialist ERPs.

DataRay

Where the useful source material spans the Protheus database, NF-e XML documents, and file shares of fiscal or quality attachments, DataRay's approach to chatting across mixed on-prem data sources fits better than a single-database connector alone.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-Inventory of AdvPL customizations and fiscal data structures in scope
-API vs. replica decision per use case
-LGPD review of the proposed architecture
-Prioritized use-case shortlist

Phase 2 . 6-8 weeks

Pilot

-Working connector for one or two use cases
-Semantic layer covering the pilot scope
-Model serving stood up in the target environment
-Pilot results reviewed against agreed success criteria

Phase 3 . Ongoing

Production

-Hardened connector and monitoring
-Full audit logging in place
-User training and rollout plan
-Change-management process for AdvPL or schema changes

Phase 4 . Ongoing

Scale

-Additional use cases added to the same platform
-Additional branches or business units onboarded
-Periodic model and infrastructure sizing review

Questions to ask any vendor, including us

A short list that separates real TOTVS Protheus AI work from a chatbot demo.

Has the vendor actually worked with AdvPL customizations and Protheus's fiscal data stack, or are they assuming a generic ERP schema?
Will the connector read through the Framework REST API, a replica, or the live production database, and what is the performance impact of each?
Where does the model run, and does any ERP or fiscal data leave Brazil or the customer's own infrastructure at any point?
How does the system handle NF-e and SPED data without risking any change to the original fiscal records?
Is every write-back gated behind a human approval step, enforced technically rather than just by policy?
How is access control enforced against Protheus's own security groups rather than a separate permission system?
What is the LGPD lawful basis and retention policy for any personal data the AI layer touches?
Can the customer retain the connector and semantic layer if they later part ways with the vendor?

Frequently asked questions

Can AI work with TOTVS Protheus's AdvPL customizations?

It has to, since most Protheus estates carry years of AdvPL customization. The practical approach is to inventory the custom routines and fields first, then build a semantic layer that documents what they mean, rather than assuming a textbook Protheus schema.

Does this replace TOTVS's own AI features like Carol?

No, and it is not positioned to. TOTVS's native AI and data platform capabilities run in TOTVS's own multi-tenant cloud; a private, on-prem or single-tenant deployment is a different option for customers who need the model and data to stay inside their own infrastructure or a Brazil-resident boundary.

How does this handle Brazil's fiscal compliance requirements like SPED and NF-e?

The AI layer stays strictly read-grounded on SPED extracts and NF-e records to help triage exceptions and answer questions; it does not generate or submit fiscal filings, and the original records remain the source of truth for any audit.

Does adding AI to Protheus require sending data outside Brazil?

No. Model serving and storage can be kept inside Brazil or whatever jurisdiction the customer's own data governance policy requires, whether that is on-prem hardware or a private, single-tenant cloud.

How long does a first TOTVS AI pilot take?

A focused pilot on one or two use cases, such as natural-language query over sales and fiscal data or ICMS exception explanation, typically runs 6 to 8 weeks after a 2 to 3 week discovery phase.

Is this relevant beyond Protheus, for Datasul or RM customers?

Yes, the same connector-plus-semantic-layer pattern applies, though the specific API and database structure differ by product, so discovery needs to confirm which TOTVS platform and version is actually in scope.

What LGPD considerations apply?

Any personal data the AI layer touches needs a clear lawful basis and a retention policy no looser than the source Protheus environment's own, with access controls that mirror Protheus's existing user permissions rather than introducing a separate model.

Related guides

Ask your ERP anything

Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English

See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.

RAG + SQL + permissions

A Private LLM Grounded on Your ERP Data

How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.

Agents + approval gates

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

ERP AI Cost Guide

What ERP AI Actually Costs: A CFO's Guide

A CFO's guide to what ERP AI actually costs: GPU hardware, model licensing, integration and connector work, and realistic ongoing run-rate ranges.

ERP AI Buyer Guide

How to Choose an ERP AI Implementation Partner

A CIO checklist for picking an ERP AI implementation partner: the architecture questions to ask, red flags, pricing models, and what to demand in the SOW.

QAD + on-prem AI

AI for QAD Adaptive ERP in automotive and industrial manufacturing

Add AI to QAD Adaptive ERP or Enterprise Edition for automotive and industrial manufacturing, grounded on QXtend and QAD's API layer, on-prem or private cloud.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows TOTVS Protheus

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides