Summary

  • E&L Produções de Software Ltda, identified in public contracts by the CNPJ 39.781.752/0001-72, provides a broad suite of public administration software whose value lies less in any particular module than in the way modules can share records, permissions, and workflows.
  • Public evidence confirms contracts, demonstrations, migration work, and live use in several municipalities, but it does not independently validate all of the company’s claims regarding client scale, number of installations, cloud protection, security, or service availability.
  • The deployment model is not uniform. E&L markets GPI as web- and cloud-based software, while procurement documents also describe installations on municipal equipment or in a municipality’s own data centre. Security, data location, and continuity must therefore be established contract by contract.
  • Integration creates practical switching costs through data conversion, customisation, staff training, interfaces, reporting calendars, and accumulated process knowledge. One public E&L contract promises ongoing availability of the generated database after termination, but leaves unanswered important questions about format, documentation, extraction testing, timing, and transition support.
  • A serious buyer should test production workflows and migration reconciliation, not just screens. It should also contract for measurable support, recovery, incident communication, audit logs, data portability, knowledge transfer, and an executable exit plan before the suite becomes the municipality’s operational memory.

One Record, Many Consequences

Imagine a municipal employee changing a single piece of information: a civil servant changes department, a supplier record is corrected, a tax debt is renegotiated, or an invoice is accepted under a contract. In a fragmented administration, that change may be re-entered into multiple systems, sent by email, printed for a file, and reconciled weeks later. In an integrated administration, the same record can affect payroll, accounting, procurement, inventory, access rights, reports, and the transparency portal. The second model can be faster and more legible.

It also makes the accuracy, availability, and portability of the shared system particularly important.

That is the operational trade-off behind E&L Produções de Software Ltda. The company’sGPI presentationdescribes a web-based public management environment covering digital documents and processes, finance, taxation, personnel, and other municipal functions. Itsmain sitelists a broader catalogue that includes accounting, procurement, warehouse, assets, fleet, human resources, health, and education. The proposition is not simply that the town hall can buy multiple applications from a single catalogue. It is that administrative events can travel through a common procedural and data environment.

The benefit is easiest to see in workflow. A purchase requisition can pass through authorisation, tendering or direct purchase, contract management, stock receipt, asset registration, accounts payable, and public disclosure. A personnel action can start with an authorised process and end at payroll, accounting entries, and an employee portal. A citizen protocol can be routed between departments with a record of who handled it and when. E&L says its document module applies ECM and BPM concepts, supports standard documents and flows, and can attach ICP-Brasil digital signatures.

These are useful capabilities if the configured process matches the law, staff understand their roles, and the records remain complete.

But integration changes the shape of operational risk. The software is no longer a desktop tool on the fringe of government. It can become the channel through which the municipality remembers who must be paid, who can approve spending, what assets exist, what a worker should receive, and whether a citizen request has stalled. A problem in a narrow module may remain narrow. A problem in shared identity, databases, hosting, permissions, or support can propagate across functions. Likewise, replacing an isolated application is a project; replacing an integrated administrative memory is an institutional transition.

The right way to evaluate E&L is therefore not to ask whether the integrated software is good or bad. It is to ask what integration is actually contracted, where it runs, what evidence shows it works, who can diagnose it, how the municipality controls its data, and what happens when the relationship ends.

E&L as Identified in Contracts

The entity examined here is E&L Produções de Software Ltda, not a product name, a presumed parent company, or an unrelated firm with similar initials. The strongest identity key in the public documents examined is the CNPJ39.781.752/0001-72. It appears on E&L’sown websiteand in municipal contract records, including the2024 IPREVITA agreement, theÁguia Branca contract register, and thePorto Velho contract portal. These records allow product and contract claims to be linked to the same operating company even when typography varies between “E&L”, “E & L”, and “EL”.

E&L states it was founded in August 1993 in Domingos Martins, Espírito Santo. Its current website gives an address on Rua João Batista Wernersbach in central Domingos Martins and describes branches or support points in Bahia, Minas Gerais, and Rio de Janeiro. The 2024 IPREVITA contract records an address on Avenida Koehler in the same municipality. The shared CNPJ resolves the entity boundary; the different addresses should be treated as dated public records, not silently merged to prove every page is current.

The company currently claims more than 800 clients, over 3,500 software installations, operations in nine states, and a workforce exceeding 600. These arecompany assertions, not independently audited measures in the evidence examined for this article. Public procurement records corroborate a significant municipal footprint in several states, but they do not establish what the company counts as a client or installation. A municipality may contract multiple modules; a city administration, a legislature, a pension institute, and a water utility may be separate clients; an installed instance may be inactive, in migration, or limited to a small function. None of these possibilities makes the headline figures false. They simply mean the figures should not be converted into market share, active user numbers, or recurring revenue without a disclosed methodology.

This distinction matters because the public evidence shows very different contract forms. The IPREVITA pension institute bought seven modules and implementation. The Águia Branca register describes a broader engagement for integrated licensing, migration, training, and support. Porto Velho purchased large financial, personnel, and tax lots across direct and indirect administration. Aracruz split its tender into lots and awarded one to E&L and another to SMARAPD. A health fund or a municipal chamber may buy a much smaller slice.

“E&L client” is therefore an identity fact about a commercial relationship, not a standardised measure of how much government E&L actually operates.

GPI Is a Process System Before a Product List

E&L’s catalogue may resemble a collection of familiar enterprise applications: accounting, budgeting, taxation, payroll, procurement, contracts, assets, inventory, protocol, education, health, and portals. The most important feature is the potential coupling between them.

TheIPREVITA contractmakes this coupling concrete. Its scope covers protocol and processes; procurement, contracts, and tenders; warehouse inventory; assets; human resources and payroll; an employee portal; and a transparency portal. The detailed requirements refer to user profiles, dates and actions, online citizen channels, document management, digital signatures, reports, and exports. This is not proof that every requirement was subsequently used continuously or used correctly. It shows what the buyer intended to connect through the software.

Workflow has at least four layers.

First, thetransaction layer: a tax assessment, a payroll calculation, a purchase order, an asset movement, or a stock issuance. These are the events that change government balances or obligations.

Second, theprocess layer: who requests, checks, approves, rejects, signs, publishes, or responds. E&L’s document product is marketed as a way to standardise these routes. This can reduce informal handoffs and create a more verifiable history, but only if the configured flow reflects real authority and exception handling rather than an idealised organisation chart.

Third, theevidence layer: documents, logs, reports, signatures, and exports that allow internal control, auditors, courts, and citizens to reconstruct what happened. An audit trail is not the same as auditability. The municipality still needs complete event logging, consistent timestamps, retained versions, understandable permission changes, and reliable links between a transaction and its supporting documents.

Fourth, thepublic service layer: employee self-service, transparency, electronic invoices, citizen protocols, and information requests. When these functions are exposed through the same vendor environment, an implementation decision inside the administrative suite can reach people who never know the vendor’s name.

Municipal evidence illustrates this external reach. Ecoporanga’selectronic information service pagesends citizens to a channel supported by E&L. Rio Novo do Sul published anE&L electronic services accreditation guide. Porto Velho’scurrent municipal websitelinks employees to a “Novo Contra Cheque - GPI-E&L” service. These are stronger signals of actual service exposure than a single contract title, though each proves only the named function at the observed date.

The integrated model can eliminate duplicate entries and enable cross-module control. It can also propagate errors. A bad supplier record can affect procurement and payments. A misconfigured role can grant authority across multiple processes. A faulty migration mapping can preserve a total while losing the transaction detail needed to explain it. The relevant architecture is therefore not simply a module diagram. It is the set of shared identifiers, tables, interfaces, permissions, and workflow dependencies through which one administrative fact becomes another.

‘Cloud’ Does Not Describe a Single Deployment

E&L’s GPI page calls the system entirely web-based and presents cloud infrastructure as a way to centralise data and access it from different locations. The page also uses broad language about internationally protected servers. This is the company’s marketing description. It does not disclose a current hosting provider, region, leasing model, list of subcontractors, recovery design, encryption implementation, service-level history, or independent assurance report.

More importantly, public contracts show that an E&L deployment is not synonymous with a single cloud topology. The IPREVITA agreement authorises use on computers belonging to the contracting institute. In 2021, Vitória da Conquista summoned E&L, as the leading bidder, to demonstrate an integrated system described as running in themunicipality’s own data centre and intranet. A browser interface can be “web” while the application and database run on municipal infrastructure. Another client may use vendor-managed hosting. A third may split components between environments. The user experience alone does not answer where data resides or who controls recovery.

This variation changes responsibility.

In a municipal data centre, the government can control hardware, network segmentation, backups, and physical access while depending on E&L for application knowledge, database structures, patches, and diagnosis. In a vendor-hosted service, E&L or its infrastructure providers control more of the operational stack, while the municipality depends on connectivity and contractual visibility into incidents and recovery. A hybrid deployment can split responsibility in ways that are hard to diagnose during an outage.

The public buyer therefore needs a deployment-specific responsibility matrix. Who patches the operating system, database, and application? Who rotates privileged credentials? Who monitors capacity and failed jobs? Where are primary and backup copies? Which party tests restoration? Who owns the domain names and certificates for public portals? Which integrations cross the internet? Who can access production data for support, and how is that access logged? If the answer is simply “cloud” or “on-premises”, the architecture has not been described precisely enough to govern it.

Data location is equally easy to oversimplify. A database physically located in Brazil can still be operationally inaccessible to the municipality if only the vendor understands its structures or controls the useful export path. A component hosted abroad can raise additional legal and contractual questions even if the municipality retains strong keys, logs, and tested exports. Location, legal control, technical access, and practical recoverability are related but distinct properties.

The public record examined does not establish a single answer for all E&L clients. It establishes the need to ask the question for each contract.

Implementation Is the First Lock-in Decision

Enterprise software becomes difficult to replace well before renewal. The decisive choices happen during implementation: which records are cleaned, which codes are mapped, which exceptions are preserved, which workflows become mandatory, which reports are recreated, which interfaces are left manual, and which employees learn enough to operate the system without constant vendor intervention.

E&L’sconsulting descriptionoffers process mapping, standardisation, manuals, and training in accounting, tax, legal, IT, human resources, and planning. Itssupport pagelists installation, maintenance, updates, and local, remote, or telephone assistance. These services reveal the true product boundary: a municipality buys not only executable code but also the translation between administrative practice and the software’s data and process model.

The IPREVITA contract explicitly includes installation, implementation, database conversion, training, customisation, migration, support, and upgrades. It requires at least eight hours of training and defines support channels during business hours. These provisions are useful, but the published agreement does not turn training into a measured competency outcome. Eight hours may be sufficient for a small familiar workflow or clearly limited public evidence for seven modules, depending on audience, prior systems, and complexity.

A procurement team should ask who must be trained, on which scenarios, with what materials, and how competence is accepted after staff turnover.

Porto Velho treated migration as a governance task rather than a single vendor deliverable. ADecember 2023 decreecreated a cross-functional working group to validate migrated data and operation of the new financial system. A separate transparency record documents payment forimplementation, data migration, and user training. The combination is instructive: paying for migration does not exempt the client from reconciling it.

Migration acceptance should work at several levels. Record counts establish whether large populations arrived. Financial control totals test whether balances match. Referential integrity checks find records that no longer link to people, suppliers, contracts, or accounting classifications. Sample reconstruction asks whether an auditor can trace selected transactions from origin to posting and document. Parallel runs compare calculations such as payroll, tax, or depreciation over an agreed period. Public service tests confirm that portals and integrations still work after the transition.

None of these can be replaced by a vendor statement that conversion completed successfully.

Local administration remains important after go-live. A2025 measure from Itaranaassigned municipal staff responsibility for managing users in the E&L system. This small public record reminds us that access governance cannot be conceptually outsourced even when technical support comes from the vendor. The municipality decides who should occupy a role, responds to personnel changes, and must periodically review privileges. The vendor may implement the mechanism, but the public authority remains responsible for authorised use.

Data quality also remains an institutional obligation. Aplanning document from São Domingos do Nortedescribed tax information recorded in the E&L system while noting legal analysis and the need to request adjustments from the vendor. The software can enforce mandatory fields and calculations; it cannot decide whether an underlying legal interpretation, cadastral record, or administrative exception is correct. Integration can make clean data more valuable, but it can also make a defective master record more influential.

What the Public Evidence Proves About Usage

Public procurement evidence is unusually useful for analysing municipal software because it exposes stages that company case studies often merge: tender scope, demonstration, contract, implementation, payment, and live service. These stages should not be treated as interchangeable.

Porto Velho offers the clearest sequence. Itselectronic procurement pagedescribes a 2022 tender for integrated planning, budget, finance, accounting, assets, warehouse, costs, personnel, and tax functions across municipal bodies. The estimated value exceeded R$6.2 million, while the portal’s posted adjudicated result was approximately R$4.0 million. The file includes objections, demonstration records, appeals, and counter-arguments rather than a frictionless award.

During the proof of concept, asession minutereported E&L scores of 96% for one lot and 88% for another. A subsequentappeal judgementdescribes an 80% threshold, contested items, and on-site diligence at E&L’s production references in Petrolina and Vitória da Conquista. Some previously failed items were reconsidered. This is significant procurement evidence: the evaluators did more than read a brochure. It is not a general product certification. A scripted demonstration proves that specified functions could be shown under test conditions; it does not of itself prove production data quality, year-end performance, cyber resilience, recovery time, or every client’s configuration.

Porto Velho’scontract pagelinks the resulting agreement to E&L’s exact CNPJ and records the original 2023 value and subsequent extensions. Payment records show implementation work and subsequent maintenance. AJanuary 2026 expense recordinvolved over R$1.4 million in services under the contract, and the city’s current homepage still exposes a GPI-E&L payslip link. Together, these records support a cautious conclusion: E&L progressed from winning a demonstration to ongoing operational use for identifiable functions. They still do not prove that every contracted module is active or meets all service objectives.

Elsewhere, evidence is more limited but revealing. Águia Branca’scontract portalrecords a 2023 E&L agreement for licensing, installation, implementation, training, customisation, migration, support, and upgrades, followed by renewals. Aracruz’s2022 procurement recordshows a more contested path: the process was suspended and rectified, then E&L received one lot while SMARAPD received another. This division is evidence against the assumption that an “integrated” purchase must place all administrative domains with a single vendor.

A 2023 academic study of an E&L implementation in Pancas reported favourable user perceptions regarding usability, trust, processing time, and direct costs. Thepublished studyis useful because it examines users rather than just procurement files. Its local survey design and limited scope mean it should not be generalised into a causal performance claim for the company’s client base. At most, it shows that one implementation can be experienced positively by the users studied.

The hierarchy of evidence is therefore:

  1. a company page proves what E&L says it offers;
  2. a tender proves what a government was looking for;
  3. a contract proves what the parties agreed to deliver;
  4. a proof of concept proves what was demonstrated under defined conditions;
  5. an implementation record proves that transition work was ordered or paid for;
  6. a live municipal link or current administrative record supports use of a particular function;
  7. operational metrics, audit findings, and tested recovery would be needed to assess sustained quality.

Collapsing these levels is how buyers confuse a broad product catalogue with a continuously operating municipal system.

The Economics Are Modular, Recurring, and Uneven

E&L does not publish a universal price list on the product pages examined. Municipal records show a pricing logic built from recurring module licensing or maintenance, one-off implementation work, and contract-specific services. The amounts vary too much in scope to support a simple per-client comparison.

IPREVITA provides an example of an unusually transparent small contract. Its 2024 agreement totalsR$54,100for one year. The schedule contains a one-time installation amount of R$100 and recurring monthly fees totalling R$4,500: approximately R$467.51 for protocol and processes, R$661.99 for procurement and contracts, R$509.06 for warehouse, R$504.03 for assets, R$1,200.67 for human resources and payroll, and R$578.37 each for employee and transparency portals. The figures describe this purchase, not E&L’s general rate card.

Águia Branca’s portal records an original 12-month value of R$396,000 for a broader engagement. Aracruz’s adjudication register gives E&L’s lot a value of approximately R$1.215 million. Porto Velho’s original contract is approximately R$4.035 million. Differences may reflect number of entities, module scope, migration complexity, user population, hosting, support, implementation, and procurement design. Dividing any value by the company’s claimed client count, municipal population, or catalogue module count would create a false unit price.

The business logic matters nonetheless. A relatively low installation line can make initial adoption inexpensive while most of the value sits in recurring licences and support. Modular pricing can allow a small institute to buy only what it needs. It can also cause the vendor relationship to expand gradually: one module establishes identifiers and staff familiarity, another consumes the same records, and subsequent purchases treat compatibility as an operational requirement.

Custom work is another economic layer. The IPREVITA agreement states that systems, versions, and customisations remain the property of E&L and that client-suggested customisations also become property of E&L. This may allow enhancements to be maintained in a single product line and reused. From the buyer’s perspective, it means that money spent specifying a local workflow does not necessarily create software it can take to a successor. The value may survive only as institutional knowledge, documentation, and data — if those were well captured.

Support pricing must also be interpreted against service definition. The same contract allows local or remote assistance and provides channels during business hours. It mentions a 48-hour deadline to replace defective items, but the public terms examined do not present a full service-level schedule for severity, response, workaround, restoration, recovery point, or financial remedy. Recurring fees are not in themselves proof of 24-hour operational coverage.

Total cost of ownership is therefore larger than the invoice. It includes municipal administrators, infrastructure where applicable, connectivity, integration maintenance, data cleaning, audit work, refresher training, changes caused by law, parallel operation during migration, and eventual exit. A low bid can still be costly if data conversion fails or a successor cannot rebuild historical records. A higher bid can still be poor value if acceptance testing does not prove that promised functions work with the municipality’s data.

Why Exit Becomes Difficult

Vendor lock-in is often discussed as if it were a contractual prohibition on leaving. In municipal administration, the strongest lock-in is operational: the cost and risk of rebuilding a working chain of records, routines, and responsibilities.

The first source is the data model. E&L’s IPREVITA contract describes converting the institute’s database into an E&L format. Once years of transactions, classifications, attachments, and workflow history accumulate, an export must preserve more than rows. It must preserve relationships, meanings, code lists, versions, and audit context. A spreadsheet of suppliers or assets can be useful while being limited public evidence to rebuild procurement history or accounting provenance.

The second source is process configuration. Approval routes, document templates, role profiles, calculation parameters, and reports embody local choices. Some are visible in manuals; others live in configuration tables or support staff habits. If the municipality has not maintained an independent process map, the running system becomes the only complete specification of how work is done.

The third source is integration. A payroll system may send accounting entries, a tax module may connect to electronic invoice services, a portal may depend on identity data, and third-party applications may consume vendor-specific layouts. Senior, for example, publishes aspecific ISS municipal export layout for E&L. This is a narrow example, not a map of E&L’s entire interface estate, but it shows the maintenance burden imposed on external systems when formats change.

The fourth source is timing. Municipal finances, payroll, procurement, and taxes have legal and operational calendars. A successor cannot always be brought in when it is technically convenient. Year-end close, budget preparation, payroll dates, tax filings, and tender deadlines may make parallel running necessary and compress the safe migration window.

The fifth source is human expertise. Users learn shortcuts, exception paths, and support contacts. Database and application administrators accumulate undocumented knowledge. If key employees leave, the vendor can become the only party able to explain why a historical record looks the way it does. Conversely, if a vendor support specialist changes, the municipality may discover that a critical custom process was never documented on either side.

None of this means a municipality should avoid integration. It means portability is a product requirement, not a final negotiation topic.

A Database Promise Is Not Yet an Exit Plan

The IPREVITA contract contains an important protection: after termination, E&L may uninstall its systems but must leave the database generated by the contracted system available to the institute. This is better than a clause that is silent on client data. It recognises that the public body must retain the administrative record even when the executable software is removed.

The clause does not answer several practical questions visible in the published agreement:

  • In which database engine,, and character encoding will the information be delivered?
  • Will attachments, signed documents, audit logs, workflow states, and deleted record histories be included?
  • Are data dictionaries, relationship diagrams, code lists, and report definitions part of the handover?
  • Can the municipality test a full export before termination?
  • For how long will E&L provide read access, and under what licence?
  • Who extracts the data, at what speed, at what cost, and through which secure channel?
  • What assistance must E&L provide to the successor?
  • How will completeness be reconciled and disputed?
  • When will vendor and subcontractor copies be deleted, and what evidence will confirm deletion?

The contract also says that moving the system between equipment may generate a separately quoted cost. This provision is not the same as an exit charge, but it illustrates why the transition economy should be agreed before dependence becomes acute.

A robust exit package would combine multiple forms of portability. The municipality should receive periodic full database exports together with documented open extracts for key domains. It should maintain independent copies of attachments and signed records. It should have an inventory of integrations and identifiers, current process and configuration documentation, and a tested read-only archive strategy. It should rehearse restoration outside of production and periodically ask a team other than the incumbent support group to interpret a sample export.

Federal governmentICT procurement materialsoffer a useful benchmark even where a particular municipal purchase is governed by different rules. Federal guidelines emphasise life-cycle cost, alternatives, migration and training, acceptance measures, security requirements, and rights to data and models. A2025 federal transition opinionhighlights return or deletion of data, knowledge transfer, and revocation of access as continuity and security concerns. These documents are not automatically binding instructions for every municipality. They are a sane test of whether a local contract treats exit as an executable service.

A Valid Signature Is Not a Secure System

E&L promotes ICP-Brasil digital signatures in its document and process environment. This can be important for municipal records. Brazil’s National Institute of Information Technology explains that digital certification can support authorship, integrity, and legal validity. The sameofficial FAQclarifies that a digital signature is not a confidentiality mechanism.

The distinction is essential. A correctly validated signature can show that a document has not changed since signing and bind the act to a certificate. It does not prove that the signer’s application account had appropriate privileges, that the terminal was not compromised, that the database is encrypted, that backups can be restored, that an administrator did not expose other records, or that the service will remain available.

Auditability also requires more than a final signed PDF. Investigators may need the path by which the document arrived, earlier versions, comments, delegation records, failed attempts, permission changes, and links to the original transaction. If these records are split across application tables, file storage, and signature validation services, retention and export must preserve the chain.

Buyers should therefore test signature workflow as a business process. Can the municipality identify the certificate, validation result, and signature time? What happens when a certificate expires or is revoked? Can a signed record be exported with the evidence needed for independent validation years later? Are rejected and superseded documents retained? Does the audit log distinguish between person, application account, and privileged administrator? These are acceptance questions, not features to infer from an ICP-Brasil logo.

LGPD Responsibility Follows the Data, Not the Brochure

E&L publishes aprivacy page, identifies a data protection contact, and states that its practices align with the Brazilian General Data Protection Law. The page is relevant evidence of the company’s privacy posture. It is not a substitute for a product-specific data processing agreement, security architecture, subcontractor inventory, retention schedule, or control test.

Municipal systems may contain tax, financial, employment, health, education, identity, and citizen contact data. The exact mix varies by module and client. Under theLGPD, public-sector processing must serve public purposes and be explained with appropriate transparency; public data must be maintained in interoperable and structured form where legal conditions apply; and processing agents must adopt technical and administrative security measures. The contract must still allocate operational obligations for the actual service.

Depending on the processing, the municipality will typically determine the public purposes and may act as controller, while a vendor processes data under instruction as an operator. Labels should follow the facts rather than being assumed from the purchase title. The agreement should specify authorised processing, access support, logging, retention, subcontracting, international transfers if any, deletion, evidence, and assistance with subject or regulatory obligations.

Incident communication deserves special attention because the party that first detects a technical event may not be the party legally responsible for notifying authorities and affected persons. CurrentANPD guidelinesstate that the controller must communicate qualifying incidents within the prescribed timeframe and that an operator must inform the controller without undue delay and provide the necessary information. A municipal contract should make this handover faster and more specific than a generic duty to cooperate: what constitutes notification, which clock starts, who is available outside business hours, what evidence is preserved, and how updates are delivered.

The public sources examined do not establish E&L’s current encryption design, privileged access management, secure development process, penetration test results, backup isolation, recovery performance, cloud region, or independent certification status. This is an evidence gap, not proof that controls are absent. A buyer should request current evidence under appropriate confidentiality and write verifiable obligations into the contract rather than converting marketing language into a security conclusion.

Continuity Evidence Is Mixed and Local

There is no responsible way to infer an overall E&L availability rate from the public records examined. They contain examples of continuous service, planned transitions, and adverse findings, but not an incident history comparable across the fleet.

The strongest adverse operational record is old and specific. An audit of the Brazilian Unified Health System in Ilhéus, generated in 2018 after fieldwork that year, reported problems with the E&L warehouse system used in health administration. Theaudit reportstated that the system had been unavailable for days, froze, lacked needed reports or routines, and was accompanied by inadequate training; auditors recommended reassessment. This is third-party documented evidence concerning one client and module at a point in time. The report does not establish the technical cause, whether infrastructure or configuration contributed, how the problem was resolved, or the current performance of E&L’s suite.

A more recent record concerns contract performance rather than a proven platform-scale outage. In May 2026, the Câmara Municipal de João Monlevade published aportaria modifying an administrative inquiryinto possible irregularities in the E&L contract 18/2023. The document references a technical report with unresolved inconsistencies and repeated execution failures, and a legal opinion indicating possible partial or irregular execution. It also preserves the company’s right to respond. No final decision was located in the public sources examined, so this is allegations under investigation, not a finding of fault.

Planned transitions reveal another continuity issue. When Aracruzintroduced an E&L electronic invoice system in 2014, the municipality warned of several days of unavailability during the transition. A2018 notice from Cachoeiro de Itapemirimreported a weekend switch to an E&L invoicing system, new credentials, and an updated integration standard. These records do not describe failed migrations. They show that even a successful replacement can interrupt public services and force external accountants or software vendors to modify their interfaces.

Positive evidence is also local. Contract extensions, payments, and Porto Velho’s current employee service link indicate sustained use of at least part of GPI. The Pancas study reports favourable user perceptions in its framework. Neither supports a universal service level.

For procurement, the lesson is to avoid both extremes. An old audit finding should not be inflated into a claim that E&L is generally unreliable. A long client list should not be inflated into proof of resilience. Continuity must be measured in the client’s own topology through monitoring, incident records, backup tests, recovery exercises, and performance at peak administrative periods.

Purchasing Is Part of the Technical Architecture

Municipal software architecture is shaped by purchasing choices: whether the administration buys a suite or multiple lots, whether it mandates municipal hosting, how it scores demonstrations, and what evidence can change an evaluator’s conclusion.

Porto Velho’s proof-of-concept record demonstrates both the value and limits of functional scoring. A threshold forces bidders to show capabilities. Appeals on individual items reveal how much depends on test wording, evidence, and evaluator interpretation. On-site diligence at production references strengthened the process, but the subsequent reconsideration of items also shows that a percentage score can mask contested judgments.

Aracruz offers a practical alternative to single-vendor concentration. It awarded separate lots to E&L and SMARAPD. IPREVITA’sdemonstration resultsimilarly approved E&L for one lot and another vendor for a pensions-related lot. A split purchase can preserve specialised competition and limit the blast radius of a platform. It can also create integration costs, duplicate identities, and disputes over which vendor owns an interface problem. There is no universally correct number of vendors; the municipality must assess both concentration risk and fragmentation risk.

Court records add another warning: a technically competent product does not cure a defective process. In Avaré, the São Paulo Court of Accounts examined a procurement and contract involving E&L and upheld findings of irregularity in the tender and agreement. The2022 session minuteis procurement governance evidence, not proof that the software failed or that E&L committed fraud. In a separate Minas Gerais case, E&L itself challenged aspects of a Monte Sião purchase; theTCE-MG case recordreflects concerns about objective feature review and procedural treatment. Together, the cases show why requirements, scoring, demonstrations, appeals, and contract terms must be audited in themselves.

Competition should be assessed at exit as well as entry. A tender may attract multiple bidders, but only the incumbent may have current knowledge, migration experience, and local workflow details. To maintain real future competition, the municipality must retain data and documentation that a challenger can inspect without relying entirely on the incumbent.

Tests That a Municipal Buyer Should Perform

The following tests derive directly from the public evidence about E&L. They are not accusations and should be applied to any integrated public administration vendor.

1. Prove contractual identity.Match the legal name, CNPJ, signing authority, support entity, hosting party, and any subcontractor. Confirm whether the party making a security or continuity promise is the party legally responsible for delivering it.

2. Define the operational scope.List each module, municipal entity, public portal, database, integration, and user group. Mark each as proposed, contracted, installed, accepted, live, or retired. This prevents a catalogue item from being reported as a working service.

3. Map the actual topology.Require a current diagram showing application components, databases, file stores, identity services, networks, hosting locations, backups, monitoring, and external interfaces. Repeat for development, testing, disaster recovery, and support access.

4. Demonstrate with municipal data.A proof of concept should use representative volumes and challenging scenarios, not just clean vendor examples. Test cancellations, retroactive payroll changes, failed purchases, partial deliveries, debt renegotiations, duplicate persons, document versioning, and permission exceptions.

5. Reconcile migration at multiple levels.Agree on record counts, financial totals, referential checks, and transaction samples before transition. Preserve source snapshots. Require signed discrepancy logs and repeat tests after each conversion.

6. Test the busiest schedule.Measure payroll close, budget execution, year-end accounting, mass tax issuance, procurement publication, and portal demand at realistic concurrency. A system that responds in a demonstration may behave differently on a municipal deadline.

7. Inspect auditability.Verify logs for creation, modification, approval, deletion, export, failed access, administrator action, and role changes. Confirm timestamps, retention, search, and export. Reconstruct a transaction without help from the person who configured it.

8. Separate signing from security.Validate ICP-Brasil evidence independently, then test account controls, privileged access, session management, vulnerability management, encryption, logging, and recovery as separate controls.

9. Contract service levels that describe outcomes.Define severity, response, workaround, restoration, recovery point, recovery time, escalation, out-of-hours coverage, and reporting. A helpdesk during business hours is not a full continuity commitment for a public portal or payroll deadline.

10. Rehearse an incident.Simulate a compromised account, inaccessible database, failed integration, and unavailable public portal. Test who detects the event, who can contain it, what the municipality can see, how ANPD-relevant information is assembled, and whether clean restoration works.

11. Cost the full life cycle.Include implementation, cleaning, interfaces, infrastructure, support, legal changes, reporting, training, staff time, contract management, parallel running, and exit. Identify changes that are included and those requiring a separate submission.

12. Test portability before award and during service.Request a full sample export with attachments, logs, and dictionaries. Load it into an independent environment or have a third party inspect it. Repeat periodically so that the exit clause remains operational rather than theoretical.

13. Preserve municipal knowledge.Require current process maps, configuration registers, interface specifications, administration guides, training materials, and decision logs. Deliverables must be updated when software or law changes, not written once at go-live.

14. Make transition a priced service.Specify overlap, successor assistance, data extraction, read-only access, credential revocation, deletion of vendor copies, and dispute handling. Set dates and acceptance criteria before termination pressure weakens the buyer’s leverage.

These tests do not eliminate dependence. They make dependence observable and governable.

What Remains Unproven

The public record is substantial enough to establish E&L’s identity, broad product scope, multiple municipal contracts, varied deployment models, and the practical importance of migration and support. It remains inadequate for several important conclusions.

There is no independently reconciled count of E&L’s active clients, live modules, users, or installations in the sources examined. There is no common measure of implementation success across municipalities. Contract values cannot be converted into company revenue because they differ in period, scope, and accounting treatment, and because a portal record may include amendments or a single contracting body.

The available public evidence does not show the current application stack, database technologies across versions, tenancy design, hosting regions, subcontractors, encryption boundaries, or recovery topology. The sources examined do not provide current independent security certification, penetration test summary, software bill of materials, vulnerability disclosure programme, public status history, or comparable incident metric. This absence should trigger diligence, not a negative assertion.

The default exit position is also unclear. One contract leaves the generated database available, but a single client agreement cannot establish E&L’s terms across the market. The public evidence does not show a standard export specification, transition API, data dictionary, deletion certificate, or tested successor handover.

Finally, the current status of the João Monlevade inquiry remains unresolved in the public records examined. The initiating document supports review of alleged performance issues; it does not establish their cause or the ultimate legal outcome. Any subsequent defence, technical finding, settlement, sanction, or closure would materially change how this matter is described.

Watch the Transition, Not Just the Renewal

The most telling future proof of E&L will not necessarily be another contract award. It will be what happens when municipalities renew, extend, move hosting, replace modules, or attempt to leave.

Watch for tenders that publish data dictionaries and migration acceptance results. Watch whether municipalities distinguish a live module from a licensed one. Watch contract amendments for hosting changes, support escalation, security obligations, and transition assistance. Watch audit findings for recurring patterns rather than isolated complaints. Watch whether public portals announce transitions with tested fallback arrangements. Watch final outcomes in ongoing administrative and judicial proceedings.

Above all, watch whether an exiting client can obtain complete and intelligible records and maintain statutory services without extraordinary incumbent dependence.

E&L’s integrated model can give a municipality what fragmented software often fails to provide: a coherent route from administrative action to accounting consequence, documentary evidence, and public disclosure. That is real operational value. The same coherence concentrates knowledge and control. If a city buys only modules and licences, it may discover too late that the most important assets were the data model, flow history, administrator knowledge, and recoverability.

The mature purchasing position is neither to reject integration nor to trust it on presentation. It is to buy standardisation accompanied by proof: proven migration, proven access control, proven recovery, proven audit history, and proven portability. A city hall can operate inside a single vendor’s software without surrendering its institutional memory — but only if exit is designed from entry.