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

> Source: https://netray.co/erp-ai/totvs-ai-integration
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for ERP

## 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.

## Kind

platform

## Erp Family

other

## Erp Products

- TOTVS Protheus
- TOTVS Datasul
- TOTVS RM

## Industries

- Manufacturing
- Distribution
- Agribusiness
- Retail

## Region

Global

## Persona

CIO

## Eyebrow

TOTVS Protheus + private AI

## Intro

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.

## Pain Points

### AdvPL expertise is scarce and expensive

**Detail:** 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

**Detail:** 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

**Detail:** 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

**Detail:** 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

**Detail:** 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.

## Use Cases

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

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

**Erp Objects:** 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

**Description:** 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.

**Erp Objects:** 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

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

**Erp Objects:** 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

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

**Erp Objects:** 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

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

**Erp Objects:** MRP/planning tables, work order and purchase order records

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

### AdvPL customization documentation assistant

**Description:** 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.

**Erp Objects:** 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

**Description:** 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.

**Erp Objects:** SPED digital bookkeeping records, NF-e transmission logs

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

## Architecture

**Overview:** 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.

**Layers:**

#### ERP connectors

**Detail:** 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.

#### Data and semantic layer

**Detail:** A documented mapping of AdvPL-customized fields, custom routines, and fiscal data structures (NF-e, SPED, ICMS configuration) into consistent business terms.

#### Model serving

**Detail:** Open-weight models served with vLLM or Ollama on customer-owned GPUs or a private cloud tenancy, sized to actual concurrency needs.

#### Retrieval and agents

**Detail:** Retrieval-augmented generation over the semantic layer plus structured query tools, with any write-back routed through a human approval step.

#### Governance and audit

**Detail:** Query-level logging mapped to Protheus's own user and permission groups, keeping fiscal and production records themselves untouched by the AI layer.

## Deployment Options

### Air-gapped on-prem

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

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

### Private or sovereign cloud

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

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

### Hybrid

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

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

## Compliance

### 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.

**Framework:** LGPD (Lei Geral de Protecao de Dados)

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

**Framework:** ISO 27001

### 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.

**Framework:** SPED and fiscal audit-trail integrity

### 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.

**Framework:** Data residency (ANPD expectations)

## Integration Notes

- 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.

## Product Fit

### Custom build

**Why:** 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

**Why:** 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.

## Engagement

### Discovery

**Duration:** 2-3 weeks

**Deliverables:**

- 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

### Pilot

**Duration:** 6-8 weeks

**Deliverables:**

- 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

### Production

**Duration:** Ongoing

**Deliverables:**

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

### Scale

**Duration:** Ongoing

**Deliverables:**

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

## Buyer Questions

- 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?

## Faq

### Can AI work with TOTVS Protheus's AdvPL customizations?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

TOTVS AI, TOTVS Protheus AI integration, on-prem AI for TOTVS, TOTVS Protheus copilot, TOTVS generative AI, AI for TOTVS AdvPL, TOTVS natural language query, LGPD AI TOTVS, private LLM TOTVS, TOTVS Datasul AI, TOTVS chatbot, AI agents TOTVS ERP, TOTVS Brazil AI

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json