QgenticQgentic
Qgentic / how it works / integration
Integration · for compliance & IT

System Integration.

Qgentic reads from your ERP and core systems; it never writes back. Read-only feeds, standard formats, no proprietary modules, no integration programme. No write-back operations are performed — your systems of record stay exactly as they were.

Discuss Integration View Demo

Read-only architecture · Strict boundary validation · Full audit trails.

Data Architecture

Read-Only Data Ingestion

The system relies on a standardised, read-only data ingestion model. Core compliance processing — validation, assembly, export — is decoupled from the data source, so an ERP migration never touches your compliance logic.

Data FeedDescription
list documentsIndex of available contracts and agreements for processing.
read documentFull-text retrieval of specific documents.
master dataEntity information, function catalogues, and vendor metadata (Names, LEIs, Locations, Contacts).
Data Validation

Strict Boundary Validation

All ingested data is validated against a strict schema prior to processing. Non-compliant records are immediately flagged with precise error paths (e.g., vendors.3.lei: invalid checksum), preventing invalid data from entering the compliance register. Downstream reporting starts from validated records only.

The integration surface: read-only by construction ERP and core systems, middleware and drop zones feed four connectors — rest, sftp, filesystem and csv — all pull-only against one boundary contract. Every record passes a schema gate that validates identifiers against their standards and refuses non-compliant records with a precise error path. The engine's validation, assembly, approval and export are decoupled from the source, every ingested byte is hashed onto the audit chain, and the write path back to the ERP does not exist: the connector interface has no write, update or delete call. § YOUR ESTATE § THE CONNECTORS § THE BOUNDARY GATE § THE ENGINE ERP & core systems SAP · Oracle · Dynamics NetSuite · Sage · GRC Your middleware SAP CPI · MuleSoft · Boomi or none — direct feeds Drop zones SFTP · share · bucket read-only mounts Four connectors, one contract rest pull · scoped bearer token sftp scheduled pull · no inbound port filesystem watched directory · stateless csv RFC 4180 batch exports PULL ONLY · NOTHING WRITES BACK The connector contract contains no write, update or delete operation. no write path into your systems of record SCHEMA GATE Every record validated before processing. vendors.3.lei: invalid checksum refused, with the path to the broken field ISO 17442 · 3166 · 4217 identifiers checked against their standards, not assumed The engine Validation, assembly, approval, export — decoupled from the source. every ingest hashed SHA-256 audit chain from the first byte read An ERP migration never touches compliance logic. new feed, same record THE WRITE PATH DOES NOT EXIST no write, update or delete call exists in the interface — read-only is architecture, not a permission setting Read-only by construction: four connectors, one boundary contract, every ingested byte validated and hashed — and no code path that could write to your ERP.
The integration surface. Four connectors cover every ERP tier — direct REST, middleware drops, SFTP pulls, batch CSV — all pull-only against one boundary contract. Every record passes the schema gate before the engine sees it, with identifiers checked against their standards and failures refused with a precise error path. The write path back to your ERP is not restricted; it does not exist.
Integration Options

ERP Compatibility Tiers

The platform supports multiple integration methods, eliminating the need for specific ERP compliance modules.

Tier 1 · Direct API Integration

Native API Support

Connects directly to native ERP APIs or reporting modules (e.g., SAP OData/BTP, Oracle Fusion REST, Dynamics 365 OData, NetSuite SuiteTalk). Uses the built-in rest connector, optionally via an iPaaS layer.

Tier 2 · Middleware Export

Automated File Transfer

Your ERP's standard reporting generates the files (SAP AL11 exports, for example). Your integration layer — MuleSoft, Boomi, SAP CPI — moves them to a drop zone, and the filesystem or csv connectors take it from there.

Tier 3 · Scheduled Flat Files

Batch CSV Exports

Supports scheduled CSV exports common in mid-market systems (e.g., Sage, NetSuite saved searches). Files are retrieved automatically from a secure drop directory or SFTP share.

All tiers move data system-to-system, with no manual re-keying. All data ingestion events are cryptographically audited.

Connection Protocols

Supported Ingestion Connectors

Connectors are configured via environment variables to match existing data extraction workflows.

filesystem Protocol

Monitors a designated directory for data updates (e.g., mounted read-only cloud buckets, network shares). The system operates statelessly, re-evaluating the directory contents during each run.

csv Protocol

Parses standard flat-file batch exports. Requires header rows and supports RFC-4180 standard quoting. Column ordering is fully flexible.

rest Protocol

Consumes data via three standard JSON API endpoints. Supports Bearer token authentication. TLS termination, IP restriction, and token management are handled at your API gateway.

sftp Protocol

Executes scheduled pulls from a secure SFTP server, avoiding complex inbound firewall modifications. Authentication credentials are encrypted and managed securely.

custom Interfaces

Extensible architecture supports proprietary integrations (Message Queues, Direct Database Views, SDKs) by implementing a standardised read-only interface.

QGENTIC_CONNECTOR=rest · QGENTIC_ERP_BASE_URL=https://gateway.example.com/api/qgentic
File Handling

Adaptive Parsing

The system dynamically adapts to native ERP output naming conventions and formatting, requiring no modifications to upstream reporting configurations.

  1. Pattern MatchingData sources are configured using flexible file pattern matching (e.g., UMSV_*.csv), accommodating default ERP naming schemes.
  2. Latest File SelectionAutomatically processes the most recent file matching the pattern, simplifying directory management.
  3. Format NormalisationHandles complex formatting issues natively, including BOMs, currency symbols, and variable delimiter standards.
  4. Calculated MetricsDerived data points and totals are computed securely within the application to maintain strict digital link requirements.
Data Mapping

Standardised ERP Field Mappings

Reference mappings for primary ERP systems. Additional fields from GRC or operational resilience tools can be merged via standard data feeds prior to ingestion.

Target Field SAP S/4HANA Oracle Fusion Dynamics 365 NetSuite
vendor.nameBUT000 / LFA1.NAME1Supplier NameVendorsV2.VendorOrganizationNamecompanyName
vendor.leiBP identification (LEI type)D-U-N-S / LEI idRegistration IDs (LEI)legalEntityId
vendor.countryLFA1.LAND1Supplier Address CountryAddressCountryRegionIdVendor Address Country
vendor.contactEmailBP Contact EmailSupplier ContactEmailemail
DocumentsCV01N, AribaProcurement AttachmentsSourcing AgreementsFile Cabinet Attachments

Metadata undergoes strict boundary validation: LEIs (ISO 17442), Countries (ISO 3166), Currencies (ISO 4217). Invalid records generate explicit failure alerts.

Security Architecture

Information Security Controls

Immutable Read-Only Access

All connectors enforce strict read-only access. The software architecture physically precludes write, update, or delete operations against source ERP systems.

Schema Validation Gates

Data undergoes rigid schema validation before processing. Malformed inputs generate precise error logs, preventing invalid data ingestion and maintaining system integrity.

Secure Transport Protocols

REST APIs authenticate with bearer tokens and enforce timeouts. TLS and access control sit at the edge gateway. SFTP runs on managed credentials.

Data Residency

Processed data, compliance registers, and final reports remain entirely within the secure deployment boundary. Air-gapped configurations feature active egress blocking.

Cryptographic Audit Logging

All system actions—including data ingestion, transformation, and export—are logged to a tamper-evident SHA-256 hash chain to support independent auditing.

Flexible Deployment Options

The software is packaged as stateless services capable of running in multi-tenant cloud, dedicated environments, or fully air-gapped local infrastructure.

Implementation

Deployment Roadmap

Integration follows a structured, fixed-scope methodology designed for rapid deployment.

  1. Configuration MappingCollaborative workshop to finalize data mappings based on your specific ERP configuration and reporting needs.
  2. Development & TestingData feeds are established and validated against the standardised interface contracts in a staging environment.
  3. Parallel ExecutionThe system is run in shadow mode alongside existing processes to verify output accuracy without operational risk.
  4. Production ReleaseSystem is promoted to live production, activating standard approval workflows and cryptographic auditing.
Discuss Implementation DORA Demo MTD Demo OpRes Demo

Maintain Your Systems of Record. Core systems connect to compliance workflows read-only — nothing is ever written back into your ERP. Contact us to discuss integration for your infrastructure.