.png)
Kyriba Integration Guide
Connect Kyriba treasury data and payment processes with enterprise systems through REST APIs, secure file exchange, SFTP, and scheduled Martini workflows.
Kyriba integration options at a glance
Kyriba integrations typically use REST APIs for bank accounts, cash positions, transactions, forecasts, and permitted payment operations. File exchange and SFTP are also important for bank statements, payment files, and other treasury data. Batch-oriented processing may be available through APIs or files, subject to tenant-specific limits and status models. Authentication can use issued API credentials, OAuth 2.0-style access where enabled, or SFTP credentials and SSH keys. Martini can schedule polling workflows, process files, map financial data, expose controlled APIs, apply validation and idempotency rules, and persist synchronization state without assuming universal webhook or SOAP coverage.
| Integration point | Supported by Kyriba? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve Bank Accounts, Cash Positions, Cash Transactions, Cash Forecasts, and permitted payment data. Available resources and operations depend on the Kyriba subscription, tenant, and API agreement. | Martini can consume Kyriba REST endpoints, apply authentication and pagination, transform responses, expose an internal API, and write results to applications, databases, files, or messaging destinations. |
| File and SFTP exchange | Yes | Exchange payment files, bank statements, cash-position files, and other financial data through approved file-transfer or bank-connectivity channels. | Martini can poll or receive files, parse agreed CSV, XML, ISO 20022, or other formats, validate control totals, archive results, and send transformed files onward. |
| Bulk, asynchronous, and batch processing | Limited | Process batches of payments, bank statements, transactions, and forecasts through APIs or file exchange. Limits, job models, and status endpoints require tenant confirmation. | Martini can orchestrate batch workflows, bound concurrency, persist job or file identifiers, poll status where available, and retry transient failures safely. |
| Authentication | Limited | API integrations require tenant-issued credentials or other configured authentication. OAuth 2.0-style access may be available, while file exchange may use SFTP credentials and SSH keys. | Martini can keep credentials and keys in protected environment configuration and apply the tenant-approved authentication scheme without hard-coding secrets. |
| Webhooks and outbound callbacks | Not confirmed | Universal webhook or callback coverage is not publicly confirmed. Any event notifications must be verified for the tenant and required Kyriba objects. | If a supported notification endpoint is available, Martini can receive it; otherwise, Martini can use scheduled polling or file exchange instead. |
| SOAP APIs | Legacy | Kyriba has an enterprise web-services history, but current SOAP resources and new-integration guidance were not verified. | Martini can consume SOAP services when Kyriba explicitly provides the required service and contract, but new designs should prefer confirmed REST or file mechanisms. |
| GraphQL APIs | Not confirmed | No verified public Kyriba GraphQL API was identified in the research. | Martini can consume GraphQL generally, but a Kyriba GraphQL integration should not be planned without tenant-specific confirmation. |
| Database and analytics access | No | Direct database access to Kyriba’s managed SaaS environment is not a standard documented integration method. | Martini should use Kyriba APIs, approved exports, or file-transfer mechanisms and can load resulting data into a permitted database or warehouse. |
How Kyriba exposes data and business events
Kyriba REST APIs
Kyriba promotes API-based integration for treasury and financial data. Depending on the tenant and licensed modules, REST resources may expose Bank Accounts, Cash Positions, Cash Transactions, Cash Forecasts, and payment-related data.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the configured Kyriba API, retrieves pages or bounded date ranges, validates the response, maps it to a canonical model, and writes it to the target system. Martini stores checkpoints only after successful validation and can expose a controlled API that shields consumers from Kyriba-specific schemas.
Implementation sequence
Kyriba file and SFTP exchange
File exchange and SFTP-style connectivity are important for bank statements, payment files, cash-position files, and other financial data. Exact formats and transmission conventions are implementation-specific.
Martini implementation pattern
Martini implementation pattern: a workflow polls or receives files through the approved transfer infrastructure, confirms that a file is complete, parses the agreed format, validates control totals, transforms the content, and archives or quarantines the result. Duplicate detection and restartability are treated as part of the workflow.
Implementation sequence
Kyriba batch processing
Treasury integrations commonly process batches of payments, statements, transactions, and forecasts. Kyriba’s exact batch limits, asynchronous job model, and status operations must be confirmed for the tenant.
Martini implementation pattern
Martini implementation pattern: a workflow creates or transmits a bounded batch, records the source and destination identifiers, polls an available status operation or processes a response file, and routes rejected items separately from successful items. Transient failures can be retried, while ambiguous payment submissions require status verification first.
Implementation sequence
Scheduled Kyriba synchronization
Universal event notifications are not confirmed for Kyriba, so scheduled polling is a practical alternative for cash positions, transactions, payment statuses, and forecasts.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow at an appropriate frequency, the workflow uses modified-date, status-date, value-date, cursor, or overlapping lookback filters where available, and a persistent state record prevents gaps and duplicates.
Implementation sequence
Common Kyriba integration patterns
Pattern 1: Submit ERP payments to Kyriba
When to use this pattern
Use this pattern when an ERP such as SAP S/4HANA, Oracle Fusion Cloud ERP, or NetSuite produces approved payment instructions that must be submitted to Kyriba. Payment creation, approval, and release should remain governed by Kyriba and treasury policy.
Integration direction
Example Mapping
| Kyriba Field | Canonical Field | Target Field |
|---|---|---|
| sourcePaymentId | payment.sourceId | Payment source identifier |
| amount | payment.amount | Payment amount |
| currency | payment.currencyCode | Payment currency |
| beneficiaryAccount | payment.beneficiary.account | Beneficiary account |
Martini implementation pattern
Martini receives or retrieves the approved batch, validates entities, currencies, beneficiaries, and approval state, and transforms the data to the tenant-approved Kyriba API or payment-file schema. It persists source and Kyriba identifiers, checks status before retrying uncertain submissions, and returns accepted, rejected, or unresolved statuses to the ERP.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- secure environment configuration
- error handling
- persistent integration state
Pattern 2: Synchronize Kyriba cash positions and transactions
When to use this pattern
Use this pattern when finance, reporting, or analytics systems need regular Kyriba balances and transaction activity. It is suitable when universal Kyriba event coverage is unavailable and scheduled retrieval is acceptable.
Integration direction
Example Mapping
| Kyriba Field | Canonical Field | Target Field |
|---|---|---|
| accountId | cash.accountId | account_id |
| balance | cash.amount | balance_amount |
| currency | cash.currencyCode | currency_code |
| valueDate | cash.asOfDate | as_of_date |
Martini implementation pattern
A scheduled Martini workflow retrieves pages using Kyriba-supported filters or an overlapping lookback window, preserves financial precision, maps account and organizational dimensions, and loads the normalized result into Snowflake or another target. Martini deduplicates by stable identifiers and advances the checkpoint only after the full extraction and validation complete.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination orchestration
- data mapping
- SQL state storage
- deduplication
- monitoring
Pattern 3: Ingest bank statements and reconcile transactions
When to use this pattern
Use this pattern when bank statements arrive through Kyriba or an approved SFTP channel and must be normalized for an ERP or reconciliation platform. It supports control-total validation and safe reprocessing of corrected files.
Integration direction
Example Mapping
| Kyriba Field | Canonical Field | Target Field |
|---|---|---|
| bankAccountId | statement.accountId | bank_account_id |
| transactionId | statementLine.sourceId | external_transaction_id |
| amount | statementLine.amount | transaction_amount |
| bookingDate | statementLine.bookingDate | posting_date |
Martini implementation pattern
Martini detects a completed file, verifies naming and control totals, parses the agreed CSV or XML format, maps bank-account identifiers, and sends normalized transactions to the target. It archives successful files, quarantines invalid files, records file and source identifiers, and prevents duplicate processing during retries.
Martini capabilities used
- workflow triggers
- file processing
- XML and JSON handling
- data mapping
- validation
- error handling
- audit logging
Pattern 4: Consolidate cash forecasts
When to use this pattern
Use this pattern when forecasts from ERP, planning, billing, or workforce systems must be consolidated in Kyriba, or when Kyriba forecasts must be distributed to planning and analytics systems.
Integration direction
Example Mapping
| Kyriba Field | Canonical Field | Target Field |
|---|---|---|
| forecastPeriod | forecast.period | Forecast period |
| entity | forecast.entityCode | Entity |
| amount | forecast.amount | Forecast amount |
| scenarioId | forecast.scenario | Scenario or version |
Martini implementation pattern
Martini collects approved forecast inputs, maps periods, currencies, entities, categories, and scenarios, applies required rounding and validation rules, and submits the result through the approved Kyriba API or file mechanism. A reverse workflow can extract Kyriba forecasts and distribute them to analytics systems, with rejected dimensions routed for correction.
Martini capabilities used
- workflows
- scheduled orchestration
- data mapping
- business rules
- financial validation
- API consumption
- file exchange
Applications commonly integrated with Kyriba
Kyriba commonly sits alongside financial systems, enterprise applications, banks, and analytics platforms. The exact direction and mechanism depend on the customer’s Kyriba modules, tenant configuration, API agreement, and participating system.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Exchange payment proposals, bank activity, cash positions, liquidity information, forecasts, and accounting results. | SAP S/4HANA → Martini → Kyriba | Martini receives approved payment or forecast data from SAP S/4HANA, validates and transforms it for the approved Kyriba API or file interface, then polls or processes status results back into SAP S/4HANA with duplicate-payment protection. |
| Oracle Fusion Cloud ERP | Synchronize payables, receivables, payment batches, bank activity, and cash forecasts with treasury operations. | Oracle Fusion Cloud ERP → Martini → Kyriba | A Martini workflow retrieves or receives ERP batches, applies currency, entity, beneficiary, and approval rules, submits the permitted Kyriba representation, and returns payment or reconciliation statuses. |
| NetSuite | Consolidate cash, payment, bank, and forecast information for organizations using NetSuite as a financial system of record. | NetSuite → Martini → Kyriba | Martini performs scheduled or event-triggered exchanges between NetSuite and Kyriba, transforms payment and cash models, stores source and destination identifiers, and handles retries without resubmitting an ambiguous payment. |
| Microsoft Dynamics 365 Finance | Integrate payment files, bank statements, cash balances, and liquidity forecasts with treasury processes. | Microsoft Dynamics 365 Finance → Martini → Kyriba | Martini validates files or API payloads from Dynamics 365 Finance, maps bank-account and organizational dimensions, exchanges data with Kyriba, and routes rejected or incomplete items for review. |
| Workday | Provide payroll, expense, supplier-payment, and accounting-related cash requirements to treasury forecasting processes. | Workday → Martini → Kyriba | Martini extracts approved forecast inputs from Workday, normalizes periods, currencies, entities, and scenarios, and submits them through the Kyriba mechanism enabled for the tenant. |
| Salesforce | Use collections, receivables, customer-payment, or cash-forecast inputs in broader treasury workflows. | Salesforce → Martini → Kyriba | Martini receives relevant Salesforce business data, applies an internal canonical model and treasury rules, then forwards approved inputs to an ERP or Kyriba endpoint as appropriate. |
| ServiceNow | Coordinate treasury operational requests, exceptions, approvals, and incidents associated with payment or bank-data workflows. | Kyriba → Martini → ServiceNow | Martini monitors Kyriba workflow outcomes or file exceptions, correlates them with payment and source identifiers, and creates or updates ServiceNow work items while returning resolution status where required. |
| Snowflake | Centralize cash positions, transactions, forecasts, and payment-status data for analytics and reporting. | Kyriba → Martini → Snowflake | A scheduled Martini workflow extracts Kyriba data through approved APIs or exports, normalizes financial dimensions and statuses, records extraction checkpoints, and loads curated datasets into Snowflake. |
How to build a Kyriba integration in Martini
Objective
Establish the tenant-approved connection to Kyriba and the participating systems without embedding credentials in workflow logic.
Instructions in Martini
- Confirm the Kyriba API agreement, enabled resources, tenant permissions, and file-transfer arrangements
- Configure API credentials or OAuth 2.0-style authentication where enabled
- Store API secrets, SFTP credentials, and SSH keys in protected environment configuration
- Use separate least-privileged credentials for development, testing, and production
Objective
Select an invocation model based on the Kyriba capability and required business latency.
Instructions in Martini
- Use a scheduler for cash positions, transactions, forecasts, and payment-status polling when events are not confirmed
- Use an approved file-transfer trigger or polling pattern for statements and payment files
- Use a Martini API when an ERP or other application needs controlled synchronous submission
- Treat tenant-specific callbacks as optional until their coverage is verified
Objective
Acquire Kyriba API responses, files, or permitted notifications while preserving traceability.
Instructions in Martini
- Retrieve resources using supported filters, pagination, or bounded batches
- Detect completed files and record filenames, checksums, and source identifiers
- Persist request IDs, payment IDs, file names, and extraction timestamps
- Do not advance a checkpoint until all required pages or files have been validated
Objective
Convert Kyriba-specific structures into a canonical model or the target system’s contract.
Instructions in Martini
- Map Bank Accounts, Cash Positions, Cash Transactions, Payments, Cash Forecasts, or FX Transactions explicitly
- Preserve currency codes, decimal precision, dates, statuses, and source identifiers
- Parse and generate only the file formats agreed with Kyriba and participating banks
- Keep reusable mappings separate from tenant-specific field overrides
Objective
Enforce financial, security, and business rules before data is written or payments are submitted.
Instructions in Martini
- Validate entities, currencies, beneficiaries, approval states, control totals, and required dimensions
- Apply idempotency using source payment, batch, transaction, or file identifiers
- Separate payment creation from approval and release operations
- Quarantine invalid records and route actionable exceptions for review
Objective
Deliver validated data to the target system and confirm that the business outcome is complete.
Instructions in Martini
- Write to the target API, database, file destination, warehouse, or messaging system
- Return payment and processing statuses to the originating application where required
- Reconcile accepted, rejected, and unresolved records using source and Kyriba identifiers
- Archive successfully processed files and retain appropriate audit metadata
Common Kyriba data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Bank Accounts | Synchronize account identifiers, currencies, ownership, and connectivity details for treasury and reconciliation processes. | SAP S/4HANA, Oracle Fusion Cloud ERP, NetSuite, Snowflake | Martini retrieves or processes the object through an approved API or file, normalizes account and currency fields, validates identifiers, and stores synchronization checkpoints. |
| Cash Positions | Distribute current or end-of-day balances by account, currency, entity, or bank for liquidity reporting. | ERP platforms, Snowflake, reporting APIs, corporate dashboards | Martini schedules extraction, applies bounded lookback or supported date filters, preserves decimal precision, maps organizational dimensions, and loads the result into target systems. |
| Cash Transactions | Exchange bank transactions, statement lines, receipts, disbursements, and reconciliation status. | SAP S/4HANA, Microsoft Dynamics 365 Finance, reconciliation platforms, Snowflake | Martini parses API or statement data, validates control totals and transaction identifiers, deduplicates overlapping windows, and routes exceptions for review. |
| Payments | Submit or track payment instructions, batches, approval status, execution status, and settlement details where the tenant permits. | SAP S/4HANA, Oracle Fusion Cloud ERP, NetSuite, ServiceNow | Martini validates payment data, persists source and Kyriba identifiers, separates submission from approval and release, and checks status before retrying ambiguous requests. |
| Cash Forecasts | Exchange forecast amounts, categories, periods, entities, versions, scenarios, and variance information. | ERP platforms, Workday, planning systems, Snowflake | Martini maps periods, currencies, entities, and scenarios, applies business rules, and supports bidirectional API or file-based consolidation. |
| FX Transactions / FX Deals | Exchange foreign-exchange exposures, trades, settlement information, and related risk data. | ERP platforms, risk reporting systems, Snowflake | Martini uses tenant-approved resources or exports, preserves financial precision, maps currencies and dates, and handles unavailable or changed fields explicitly. |
Authentication and security considerations
Tenant-specific authentication
Kyriba authentication must be confirmed against the customer’s tenant and API agreement. API credentials or OAuth 2.0-style client authentication may be available for REST access, while file exchange may use SFTP credentials and SSH keys.
Least privilege and protected secrets
- Use service accounts with only the Kyriba objects and operations required by the workflow.
- Store API secrets, client credentials, SFTP passwords, and private keys in protected Martini environment configuration.
- Use separate credentials for development, testing, and production.
- Apply HTTPS/TLS for API communication and restrict access to payment operations.
Payment data protection
Payment details, bank-account identifiers, and personally identifiable information should be masked in logs. Approval, release, and authorization controls remain governed by Kyriba and the organization’s treasury policy.
Operational considerations for Kyriba integrations
Rate limits and pagination
Confirm Kyriba quotas, concurrency limits, pagination style, and asynchronous status behavior before production deployment. Use bounded concurrency, stable sorting, and exponential backoff for transient failures.
Checkpoints and idempotency
Persist synchronization checkpoints only after complete validation. Use overlapping lookback windows when necessary and deduplicate by stable Kyriba identifiers. Payment retries require an existing-payment check before resubmission.
Financial and file validation
- Preserve exact decimal precision and controlled currency values.
- Validate file size, checksum, record counts, control totals, encoding, dates, and XML namespaces.
- Use archive and quarantine locations and make file processing restartable.
Schema and monitoring
Treat API schemas, file formats, enumerations, and status values as versioned contracts. Monitor authentication failures, rejected payments, missing statements, stale cash positions, reconciliation mismatches, and processing delays.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than one endpoint
Martini coordinates Kyriba APIs, file-transfer processes, ERPs, banks, databases, warehouses, and operational applications in one workflow rather than embedding logic in isolated scripts.
Reuse mappings and controls
Reusable workflows, mappings, validation rules, checkpoints, and error paths make treasury integrations easier to maintain as Kyriba modules, tenants, and target systems evolve.
Support multiple operating models
Martini supports scheduled polling, API-led integration, batch processing, file exchange, and controlled API exposure. This is useful when Kyriba event coverage varies by tenant or object.
Improve reliability and visibility
Centralized error handling, idempotency, retries, reconciliation, protected configuration, and workflow monitoring provide stronger operational controls than unmanaged point-to-point scripts.
Frequently asked questions
Kyriba can be integrated through REST APIs, approved file exchange and SFTP, and tenant-specific batch or web-service mechanisms. Enterprise workflows commonly exchange Bank Accounts, Cash Positions, Cash Transactions, Payments, Cash Forecasts, and FX Transactions with ERPs, banks, reporting platforms, and data warehouses.
Yes. Martini can integrate with Kyriba by consuming confirmed Kyriba REST APIs, processing approved files through SFTP or other supported transfer infrastructure, scheduling synchronization workflows, transforming treasury data, and exposing controlled APIs for other applications. Tenant-specific resources, authentication, and permissions must be confirmed.
No. A dedicated Kyriba connector is not required. Martini can use Kyriba’s confirmed native integration mechanisms, including REST APIs, approved file exchange, SFTP, and any tenant-specific callbacks or web services that Kyriba makes available.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Kyriba with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Kyriba, infrastructure providers, banks, or other third-party systems depending on subscriptions, usage, and deployment.
REST APIs are the primary API-led option when the required resources are enabled for the tenant. File exchange and SFTP remain important for bank statements, payment files, and batch treasury processes. SOAP should be treated as legacy and used only when Kyriba explicitly provides the required service. GraphQL is not confirmed.
Universal webhook or callback coverage is not confirmed. The required tenant and Kyriba objects should be checked for supported notifications. When event coverage is unavailable, Martini can use scheduled polling, approved file exchange, or batch processing.
Martini can use supported modified-date, value-date, status-date, cursor, or pagination controls. If a reliable change marker is unavailable, it can use an overlapping lookback window and deduplicate by Kyriba identifiers. Checkpoints should advance only after all pages and validations succeed.
Martini can persist source payment and Kyriba identifiers, apply idempotency rules, validate payment data before submission, and separate transient failures from business rejections. An ambiguous payment submission should be checked in Kyriba before retrying rather than submitted again automatically.
Related Martini documentation
Workflows
Data
Connect Kyriba with your enterprise systems
Use Martini to build secure, observable Kyriba integrations across APIs, files, ERPs, banks, and analytics platforms.