Kyriba to Databricks: How to Move Your Data

Moving Kyriba into Databricks puts treasury data where it can be modelled rather than only reported. Kyriba knows your cash positions and bank balances. It does not know what is about to be invoiced, what payroll looks like next month, or what your sales pipeline implies, and forecasting needs all of it.

This guide covers the managed path with Airbyte. The thing to get right is a distinction that looks like a detail and is not: two of the five streams come in end of day and intraday variants, and mixing them produces figures nobody can reconcile.

Kyriba to Databricks at a glance:

Why move data from Kyriba to Databricks?

Two situations account for most of these pipelines.

The first is cash forecasting that uses more than treasury data. A model predicting your position in six weeks wants receivables, payroll, committed spend and pipeline alongside actual balances, and a lakehouse is where those meet and where the modelling happens.

The second is history for its own sake. Kyriba is built for operating treasury rather than for analysing years of it, and questions about how balances behave seasonally or how a banking change affected liquidity need a long series. If you only need today's position, Kyriba shows you that already.

What do you need before you start?

Short list, and the credential type carries an operational obligation:

A Kyriba username and password. The connector authenticates with basic auth rather than a token or key. The Kyriba source documentation covers the fields, including your Kyriba domain.

A service account, and a rotation plan. Because passwords expire under most treasury security policies, and a pipeline built on somebody's personal login fails the day their password changes. Find out the rotation interval and put the renewal in a calendar rather than discovering it from a failed sync.

A decision about end of day versus intraday. Both bank balances and cash balances come in two variants, and they answer different questions. Establish with your treasury team which one your reporting should be built on before you model anything.

Unity Catalog access and a governance conversation. Each stream becomes a table in Unity Catalog and the connector needs permission to create Volumes for Avro staging. Agree the catalog and schema with whoever owns financial data access, because bank balances are not something to land in a general analytics schema.

Note also the optional end date, which bounds the last date replicated and is useful when you want a fixed historical extract rather than an ongoing feed.

How do you build a Kyriba to Databricks pipeline in Airbyte?

Step 1: Settle the balance question with treasury

Ask which balance your treasury team considers authoritative for reporting. End of day is the settled figure and the one that reconciles with statements; intraday reflects the position during the day and moves. Getting this agreed now prevents a model built on the wrong series.

Step 2: Configure the Kyriba source

Click Sources in the left navigation, then New Source, and select Kyriba, following adding a source. Supply your domain, the service account username and password, and a start date, plus an end date if you want a bounded extract.

Step 3: Configure the Databricks destination

Click Destinations, then New Destination, and select Databricks, following adding a destination. Supply your workspace details, the catalog and schema, and authentication. Put treasury data in a schema of its own with deliberate grants rather than alongside general analytics.

Step 4: Keep the balance variants in separate tables

Click Connections, then New connection, select your streams and a sync mode. Take both variants if you want them, and keep them as separate tables rather than combining them, then build your reporting views on whichever your treasury team nominated.

Daily is the natural cadence for end of day balances. If you take intraday as well, it wants a more frequent schedule to be worth having at all, which is another reason to keep the two on separate connections.

Why are end of day and intraday not interchangeable?

Because they describe different moments. An end of day balance is the settled position once the day's activity has cleared, and it is what reconciles against a bank statement. An intraday balance is a snapshot taken while money is still moving, so it reflects a position that has not finished happening.

Both are legitimate and they answer different questions. Intraday is for operational decisions during the day, such as whether a payment can go out. End of day is for reporting, reconciliation and anything a model is trained on, because it is stable and comparable across days.

Combining them into one table is the failure to avoid, because the resulting series mixes settled and unsettled figures and no query can separate them afterwards. Keep them apart in your bronze layer, build silver on the end of day series, and expose intraday separately for anyone who genuinely needs it.

How should you model treasury data in a lakehouse?

Land all five streams as bronze, then build a silver layer where accounts resolve to something human-readable and balances carry the currency and entity they belong to. Treasury data references accounts and banks by identifier, and a forecast against opaque codes is not something anyone will trust.

Currency deserves particular care. A group holding balances in several currencies needs a conversion rule and a rate source agreed with finance, and mixing converted and unconverted figures is the other common way this dataset becomes unreliable. Decide it once in the silver layer.

Then keep bronze, because treasury figures get audited. Being able to show exactly what Kyriba returned on a given day, before any modelling, is worth the storage on a dataset where somebody may eventually ask you to prove a number.

Frequently asked questions

Should I use end of day or intraday balances?

End of day for reporting, reconciliation and modelling, because it is settled and comparable. Intraday for operational decisions during the day. Keep them in separate tables.

How does the connector authenticate?

With a username and password using basic auth. Use a service account and plan for password rotation, since treasury policies usually enforce expiry.

Which streams are available?

Accounts, bank balances in end of day and intraday forms, cash balances in the same two forms, and cash flows.

Can I pull a fixed historical range?

Yes. The optional end date bounds the last date replicated, which suits a one-off extract rather than an ongoing feed.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want Spark or SQL models resolving account identifiers and handling currency conversion, which is where the decisions belong.

Get your Kyriba data into Databricks

Agree with treasury which balance is authoritative, keep the two variants in separate tables so the series never mixes settled and unsettled figures, use a service account with a rotation plan, and keep the bronze layer because treasury numbers get audited.

Airbyte's connector catalog includes 600+ pre-built connectors, so treasury data can sit beside the receivables and pipeline data a forecast needs. For the same source in a warehouse, see Kyriba to Snowflake, and for the currency reference data finance will want alongside it, Exchange Rates API to Snowflake.

Start syncing now →