Back to Help Center
Integrations5 min read

Validating an ERP Without a Sandbox

What Kolva asks for when an ERP vendor does not provide a public sandbox: metadata, small anonymized samples, module scope, and read-only access.

Some ERP vendors do not provide a public sandbox. Kolva can still prepare the integration before a POC by reviewing the tenant metadata, small anonymized samples, module scope, and the exact read-only permissions your IT team plans to grant.

What We Ask For

The goal is to verify the integration shape before any production sync. A small technical pack is enough to remove most uncertainty:

  • Metadata API or equivalent — OData $metadata, OpenAPI schema, exposed REST objects, available tables or views, ERP version, and installed modules.
  • 10 anonymized rows per entity — clients, products, orders, customer invoices, invoice lines, open receivables, vendor bills, GL entries, stock, or movements depending on scope.
  • Field and object names — screenshots or exports showing the real tenant field names for amount, paid amount, balance, due date, tax, currency, and status.
  • Active modules — Accounts Receivable, Accounts Payable, General Ledger, Inventory, Sales Orders, Purchase Orders, Manufacturing, Fixed Assets, or Payroll when relevant.
  • Planned read-only access — a dedicated role with no write permission and access limited to the entities in scope.

Why It Matters

ERP documentation describes the product. Your tenant describes the truth Kolva will actually read. Versions, country packs, custom fields, modules, and permissions can change the available data shape.

Metadata

Confirms the real objects and fields exposed by your tenant.

Samples

Reveal date formats, amount signs, currencies, statuses, taxes, and edge cases.

Screenshots

Help finance and IT teams agree on the business meaning of each field.

Module scope

Prevents a connector from looking incomplete when the module is not active.

Read-only access

Keeps the POC aligned with least-privilege security reviews.

ERP Paths We Track

For ERP families where sandbox access is gated, Kolva keeps a clear validation path instead of making a broad compatibility claim.

  • NetSuite — Oracle partner or SuiteApp path.
  • Workday — Developer tenant through partnership.
  • Epicor — Partner or demo tenant.
  • Infor — ION API partner tenant.
  • JD Edwards — Internal demo VM or client pilot.
  • Oracle EBS — Internal demo VM or client pilot.

How Kolva Communicates Coverage

Kolva validates ERP coverage by entity, not by vague global labels. A tenant can be ready for customers, invoices, and receivables while stock, manufacturing, or payroll still need a separate review.

Good to know

The preparation pack does not require write access to your ERP. It is designed to help both teams confirm the data contract before the POC.

Qualification Checklist

  • ERP name and exact version confirmed.
  • Active modules listed.
  • Metadata or API schema shared.
  • Small anonymized samples shared for critical entities.
  • Open, partial, paid, and overdue financial examples included.
  • Read-only access scope agreed with IT.
  • POC scope limited to exposed entities.

Was this article helpful?

Related Articles