Integration types

INTERA integrations can connect to many different categories of external systems. Each system type has its own data structure, terminology, access method, and operational logic.

The purpose of an INTERA Integration Module is not to copy the external system. The purpose is to expose useful business data from that system in a clean, structured, and role-friendly way.

A good integration should answer these questions:

- What business objects does this system manage?
- Which DataSources can INTERA request from it?
- Which entities should be synchronized as Assets?
- Which Metrics can be calculated from its data?
- Which time periods or operational windows does the system use?
- Which errors or unavailable states should INTERA understand?

The following sections describe common integration types and the typical data they may provide.

Billing systems #

Billing systems are one of the most important integration categories for INTERA.

They usually contain information about customers, services, products, invoices, subscriptions, usage, payments, balances, activations, deactivations, and commercial status. In telecom, SaaS, managed services, and other recurring-revenue businesses, the billing system is often one of the main sources of operational truth.

Typical DataSources from a billing system may include:

- customers
- customer_balance
- invoices
- payments
- active_services
- subscriptions
- product_usage
- service_activations
- service_deactivations
- overdue_invoices
- monthly_revenue

Typical Assets synchronized from a billing system may include:

- customers
- products
- services
- contracts
- subscriptions

Typical Metrics may include:

- monthly revenue
- unpaid balance
- overdue amount
- number of active services
- number of suspended services
- activations this month
- deactivations this month
- average revenue per customer

Billing integrations must be especially careful with time context. Billing periods, invoice issue dates, payment dates, due dates, and service activation dates may all produce different answers to what looks like the same business question.

For example, “revenue this month” may mean invoiced revenue, recognized revenue, collected revenue, or projected recurring revenue. The integration should make these distinctions clear.

Accounting systems #

Accounting systems contain financial records used for bookkeeping, reporting, compliance, payments, receivables, payables, bank reconciliation, and financial control.

Typical DataSources from an accounting system may include:

- invoices
- credit_notes
- payments
- bank_accounts
- bank_transactions
- accounts_receivable
- accounts_payable
- supplier_balances
- customer_balances
- chart_of_accounts
- journal_entries

Typical Assets synchronized from an accounting system may include:

- customers
- suppliers
- bank accounts
- legal entities
- invoices

Typical Metrics may include:

- cash balance
- total receivables
- overdue receivables
- total payables
- overdue payables
- payments due this week
- payments received this month
- supplier debt
- customer debt

Accounting integrations should not assume that accounting values match billing values. In many companies, billing and accounting systems use different dates, statuses, currencies, exchange rates, and approval workflows.

This makes accounting integrations especially useful for reconciliation. INTERA can compare billing invoices against accounting invoices, billing balances against accounting balances, or expected payments against actual bank movements.

Accounting DataSources should clearly document which date field they use:

- invoice issue date
- posting date
- due date
- payment date
- bank transaction date
- accounting period

Banking API integrations #

Banking API integrations connect INTERA to bank accounts, payment platforms, open banking providers, or financial institutions that expose account and transaction data through an API.

These integrations are useful for finance, accounting, treasury, collections, reconciliation, and executive visibility. They allow INTERA to compare expected financial activity from billing, accounting, ERP, or CRM systems against actual bank movements.

Typical DataSources from a banking API may include:

- bank_accounts
- account_balances
- account_transactions
- incoming_payments
- outgoing_payments
- pending_transactions
- card_transactions
- payment_status
- currency_balances
- exchange_rates

Typical Assets enriched by banking integrations may include:

- bank accounts
- legal entities
- customers
- suppliers
- invoices
- payment references
- currencies

Typical Metrics may include:

- current cash balance
- available balance
- incoming payments today
- outgoing payments today
- payments received this month
- payments pending confirmation
- unmatched bank transactions
- customer payments not allocated
- supplier payments executed
- bank balance by currency

Banking integrations are especially useful for reconciliation.

For example:

- accounting payments vs actual bank transactions
- billing invoices vs incoming customer payments
- supplier payment schedule vs outgoing bank transfers
- expected cash position vs actual bank balance
- customer payment references vs open invoices

A banking integration should normally be read-only unless write-capable payment actions are explicitly approved. Reading balances and transactions is much safer than initiating payments or modifying beneficiaries.

Recommended default mode:

Read-only:
- account balances
- transaction history
- incoming and outgoing payments
- payment status
- currency balances

Write-capable, only if explicitly approved:
- initiate payment
- approve payment
- cancel payment
- create beneficiary
- update payment instruction

Banking APIs require strict security handling. Credentials, access tokens, refresh tokens, certificates, private keys, and consent identifiers must be treated as secrets. They should never be hard-coded, logged, displayed in error messages, or included in sample documentation.

Common configuration parameters may include:

- API base URL
- client ID
- client secret
- access token
- refresh token
- certificate
- private key
- consent ID
- account ID
- company ID
- default currency
- timezone

Banking integrations should also handle consent and authorization expiry clearly. In many banking API environments, access may expire or require renewal. INTERA should be able to show that a banking connection is no longer authorized, rather than simply showing missing data.

Useful banking error states include:

- authorization expired
- consent revoked
- invalid credentials
- account unavailable
- transaction feed delayed
- bank API unavailable
- rate limit reached
- unsupported account type
- incomplete transaction data

Time context is important for banking data. A transaction may have several relevant dates:

- transaction date
- booking date
- value date
- settlement date
- statement date

The integration should document which date is used by each DataSource and Metric. For example, “payments received this month” may produce different results depending on whether it is based on transaction date, booking date, or value date.

A banking transaction response should include stable identifiers wherever possible.

Recommended transaction fields:

- transaction ID
- account ID
- amount
- currency
- direction
- transaction date
- booking date
- value date
- counterparty name
- counterparty account, where available
- payment reference
- description
- status
- source
- generatedAt timestamp

Banking integrations should not assume that every transaction can be matched automatically. Payment references may be missing, inconsistent, shortened, duplicated, or entered manually by customers. For this reason, banking integrations should expose enough raw reference information for INTERA reconciliation rules to match payments against invoices, customers, suppliers, or accounting entries.

CRM #

CRM systems manage sales activity, customer relationships, leads, opportunities, contacts, accounts, deals, pipelines, notes, and customer communication history.

Typical DataSources from a CRM may include:

- accounts
- contacts
- leads
- opportunities
- sales_pipeline
- closed_deals
- lost_deals
- activities
- tasks
- notes
- customer_owner

Typical Assets synchronized from a CRM may include:

- customers
- prospects
- contacts
- accounts
- opportunities

Typical Metrics may include:

- open pipeline value
- weighted pipeline value
- deals closing this month
- overdue sales tasks
- inactive accounts
- new leads
- conversion rate
- lost opportunities
- sales forecast

CRM integrations are useful for sales roles, account management roles, customer operations, and executive dashboards.

CRM data is often less strict than billing or accounting data. Names may be inconsistent, records may be duplicated, and important fields may be optional. A good CRM integration should therefore pay special attention to Asset Mapping and stable identifiers.

For example, a CRM account should be mapped carefully to the same INTERA customer Asset used by billing, accounting, ticketing, and service systems.

ERP #

ERP systems often contain broad operational and financial data across multiple business functions. Depending on the ERP, it may manage purchasing, inventory, sales orders, accounting, manufacturing, logistics, HR, projects, maintenance, procurement, and approvals.

Typical DataSources from an ERP may include:

- customers
- suppliers
- purchase_orders
- sales_orders
- inventory_items
- stock_levels
- warehouses
- work_orders
- invoices
- payments
- projects
- approvals

Typical Assets synchronized from an ERP may include:

- customers
- suppliers
- products
- warehouses
- inventory items
- projects
- orders
- employees

Typical Metrics may include:

- open purchase orders
- overdue approvals
- stock value
- low-stock items
- order backlog
- supplier delivery delay
- project cost
- inventory turnover
- pending invoices

ERP integrations can be broad. For this reason, they should be divided into clear DataSources and entity providers instead of exposing one large generic ERP dataset.

A good ERP integration should avoid returning “everything”. It should expose controlled business datasets that are useful for specific INTERA role packages.

For example:

Good:
- purchase_orders_due_this_week
- low_stock_items
- supplier_payment_summary

Poor:
- all_erp_tables
- full_database_dump
- generic_report

Navigation systems #

Navigation systems provide location, route, movement, geospatial, and status data. They are common in fleet management, logistics, maritime, aviation, field service, and vehicle tracking environments.

Typical DataSources from a navigation system may include:

- current_positions
- position_history
- routes
- stops
- geofences
- estimated_arrival_times
- speed_history
- distance_travelled
- route_deviation
- last_known_location

Typical Assets synchronized from a navigation system may include:

- vessels
- trucks
- vehicles
- containers
- equipment
- mobile teams

Typical Metrics may include:

- current location
- last update time
- distance travelled
- estimated arrival time
- route deviation
- stopped time
- average speed
- geofence status
- offline duration

Navigation integrations must handle time and coordinates carefully. The integration should clearly indicate the timestamp of each position, the coordinate system used, and whether a position is live, delayed, estimated, or missing.

Location data can become stale quickly. INTERA should be able to distinguish between a valid recent position and an old position that should be treated as delayed or unreliable.

Recommended fields for position data:

- asset ID
- latitude
- longitude
- timestamp
- speed
- heading
- source
- accuracy, if available
- status

Logistics systems #

Logistics systems manage movement of goods, shipments, deliveries, routes, warehouses, vehicles, drivers, containers, orders, and delivery exceptions.

Typical DataSources from a logistics system may include:

- shipments
- delivery_orders
- routes
- vehicles
- drivers
- warehouses
- containers
- delivery_status
- delayed_deliveries
- proof_of_delivery
- exceptions

Typical Assets synchronized from a logistics system may include:

- shipments
- trucks
- drivers
- warehouses
- customers
- containers
- routes

Typical Metrics may include:

- deliveries due today
- delayed deliveries
- on-time delivery rate
- average delivery delay
- open exceptions
- warehouse backlog
- vehicle utilization
- failed deliveries
- route completion status

Logistics integrations usually depend on operational windows rather than simple calendar periods. For example, a delivery may belong to a route date, dispatch window, delivery slot, warehouse cutoff, or customer appointment time.

The integration should clearly document which time fields are available and how delivery status is defined.

Useful status examples:

- planned
- dispatched
- in transit
- delayed
- delivered
- failed
- cancelled
- exception

Manufacturing systems #

Manufacturing systems manage production orders, work centers, materials, machines, shifts, quality checks, downtime, defects, and output.

Typical DataSources from a manufacturing system may include:

- production_orders
- work_orders
- machine_status
- production_output
- downtime_events
- material_consumption
- quality_checks
- defects
- shifts
- work_centers

Typical Assets synchronized from a manufacturing system may include:

- machines
- production lines
- products
- work centers
- batches
- materials
- operators

Typical Metrics may include:

- production output
- planned vs actual output
- machine downtime
- defect rate
- scrap rate
- shift performance
- material shortage
- order completion status
- production delay

Manufacturing integrations should pay special attention to shift-based time context. A production metric may be calculated by calendar day, production shift, batch, work order, machine, or production line.

For example, “output today” may be less useful than:

- output for current shift
- output for work order
- output for production batch
- output by machine
- output by production line

A good manufacturing integration should expose enough context for INTERA to connect production results with assets, time windows, and operational exceptions.

Shipmanagement systems #

Shipmanagement systems manage vessels, certificates, maintenance, crew, procurement, safety, compliance, technical operations, purchasing, defects, inspections, and voyage-related operational data.

Typical DataSources from a shipmanagement system may include:

- vessels
- certificates
- certificate_expiry
- planned_maintenance
- work_orders
- defects
- crew_assignments
- purchase_orders
- requisitions
- safety_events
- inspections
- voyage_data

Typical Assets synchronized from a shipmanagement system may include:

- vessels
- crew members
- equipment
- suppliers
- certificates
- work orders
- purchase orders

Typical Metrics may include:

- certificates expiring soon
- overdue maintenance
- open defects
- vessel readiness
- overdue purchase orders
- crew compliance status
- safety incidents
- inspection findings
- technical off-hire risk

Shipmanagement integrations are highly role-dependent. A Technical Superintendent, Fleet Manager, HSQE Manager, Crewing Manager, Procurement Manager, and Finance Controller may all need different views of the same underlying systems.

For example, the same vessel Asset may have Metrics from:

- maintenance systems
- certificate systems
- procurement systems
- crew systems
- navigation systems
- weather feeds
- accounting systems

Shipmanagement integrations should therefore provide stable vessel identifiers and clear Asset Mapping support.

Time context is also important. Certificates use expiry dates. Maintenance uses planned and completed dates. Procurement uses requisition, approval, order, and delivery dates. Crew uses assignment periods. Voyage data uses operational windows.

Telecom/Network systems #

Telecom and network systems manage services, customers, circuits, SIMs, terminals, routers, devices, links, bandwidth, usage, tickets, alarms, activations, provisioning, and network status.

Typical DataSources from telecom or network systems may include:

- customers
- services
- circuits
- devices
- terminals
- sims
- usage_records
- bandwidth_usage
- network_status
- alarms
- outages
- tickets
- activations
- provisioning_status

Typical Assets synchronized from telecom or network systems may include:

- customers
- services
- products
- devices
- terminals
- SIMs
- sites
- circuits
- network nodes

Typical Metrics may include:

- active services
- failed activations
- open alarms
- service availability
- data usage
- customer usage
- network uptime
- ticket response time
- unresolved incidents
- service degradation
- offline devices

Telecom integrations are especially useful for reconciliation because data often exists in multiple systems. For example, billing may show that a service is active, while the network system may show that the service is offline, unprovisioned, suspended, or not found.

Common reconciliation examples:

- billing services vs network services
- active SIMs vs billed SIMs
- active terminals vs customer contracts
- network alarms vs open tickets
- usage records vs customer billing
- provisioning status vs sales activations

Telecom/network integrations should expose clear service identifiers, product codes, customer identifiers, device identifiers, and status values. Without reliable identifiers, reconciliation becomes difficult.

Network data also has freshness requirements. A status value from five minutes ago may be useful, while a status value from three days ago may indicate a sync problem. Integrations should include update timestamps wherever possible.

Weather / external data feeds #

Weather and external data feeds provide environmental, market, operational, regulatory, or public data that can enrich INTERA dashboards and rules.

Weather data is useful for shipping, logistics, construction, field service, agriculture, aviation, energy, and outdoor operations. Other external feeds may include exchange rates, fuel prices, port data, vessel AIS data, risk scores, public holidays, sanctions lists, commodity prices, or regulatory updates.

Typical DataSources from weather or external feeds may include:

- current_weather
- weather_forecast
- wind_forecast
- sea_state
- storm_alerts
- temperature_history
- exchange_rates
- fuel_prices
- public_holidays
- port_status
- external_risk_scores

Typical Assets enriched by external feeds may include:

- vessels
- ports
- routes
- trucks
- warehouses
- customer sites
- countries
- regions
- currencies

Typical Metrics may include:

- wind speed
- wave height
- storm risk
- weather delay risk
- exchange rate
- fuel price
- port congestion level
- holiday impact
- external risk score

External feeds are usually not the main system of record. Instead, they provide context that helps INTERA interpret operational data.

For example:

- A vessel delay may be explained by sea state or port congestion.
- A logistics delay may be affected by weather or public holidays.
- A finance Metric may be affected by exchange rates.
- A fleet risk score may be affected by weather alerts.

External data feed integrations should clearly document:

- source of the data;
- update frequency;
- coverage area;
- units of measurement;
- timezone;
- data freshness;
- usage limits;
- confidence or accuracy notes, where available.

Because external feeds may affect operational decisions, integrations should expose timestamps and source information wherever possible.