KriyaGo - Blog #APIIntegration

Oracle OPERA to General Ledger: Daily Hotel Revenue | KriyaGo

Fri, 09 Oct 2026 15:28:42 -0400

The short answer

Hotel owners can automate daily revenue posting by pulling each property's closed business day from Oracle OPERA, through the Oracle Hospitality Integration Platform (OHIP) for OPERA Cloud or through exports for on-premises OPERA, and mapping it to the owner's chart of accounts. An integration layer then posts a balanced journal entry to the accounting system the owner uses, such as Yardi, MRI, or M3, and reconciles cash and card settlements against the bank. The result is daily, consistent revenue across every hotel, ready for investor reporting, without anyone re-keying a night audit report.

Key takeaways

• Hotel revenue lives in the PMS, but owners report from a real estate or investment ledger.

The gap is usually closed with spreadsheets.

• OHIP makes OPERA Cloud data available through APIs and business events,

including back-office operations and finance data, so that the daily posting can be automated.

• The OPERA Cloud migration is the right moment to fix it.

On-premises OPERA 5.6 has Oracle Premier Support until December 2027, and older interfaces must be rebuilt for the cloud anyway.

• Mapping is the hard part, not the connection.

Transaction codes have to map to USALI departments and to the owner's general ledger, entity by entity.

• KriyaSync,

KriyaGo's integration middleware, connects OPERA and OHIP to the systems real estate owners already run, such as Yardi, MRI, and M3.

Why hotel revenue is hard for real estate accounting

A hotel is an operating business inside a real estate asset. That creates a specific problem for owners whose finance teams are built around leases and rent rolls.

Revenue is generated every night, not every month.

An office or apartment building bills rent on a schedule. A hotel creates revenue every night from rooms, food and beverage, parking, resort fees, and dozens of other charges. Each property runs a night audit that closes the business day in the PMS. For an owner with ten hotels, that's more than 3,600 business days a year that need to reach the books.

The source system is a hotel system.

Many hotels, particularly full-service and branded properties, run Oracle OPERA as their property management system. OPERA is built for front-desk, reservation, and folio operations. It isn't built for fund accounting, entity consolidation, or investor waterfalls. Owners, REITs, and investment managers report from a different ledger: often Yardi Voyager or MRI on the real estate side, or a hotel accounting platform such as M3 when a management company keeps the books.

The data passes through many hands.

In a typical setup, the hotel's night auditor runs the reports. A management company accountant keys a daily revenue journal into its own system. Then, monthly, the owner's team receives a financial package and re-keys or uploads it into its own ledger. Every hand-off adds delay and a chance of error, and the owner sees results weeks after the stay.

Cloud migration is changing the plumbing.

Oracle's integration platform, OHIP, gives OPERA Cloud a self-service way to use APIs and subscribe to business events. Its API catalog covers reservations, hotel operations, configuration, and data. It includes a Back Office Operations API for reconciling guest folios and processing credit card transactions, and data APIs that cover finance subject areas.

For hotels still on premises, the clock is running. According to Chatlyn's summary of Oracle's support policy, OPERA 5.6, the last on-premises release, has Premier Support until December 2027, after which it moves to Sustaining Support. The software keeps running, but new fixes and certifications stop. Moving to OPERA Cloud also means rebuilding older interfaces, such as OXI, on OHIP. Any revenue export built on the old system has to be redone anyway, so the migration is the natural time to automate it properly.

What daily revenue posting actually involves

Automating the daily revenue journal sounds like a single export. In practice, it's a chain of five steps, and each one has its own failure point.

Step 1: Close the business day

The night audit rolls OPERA to the next business date, posts room and tax charges, and freezes the day's figures. Automation should run only after the audit has finished. Pulling data mid-audit is one of the most common causes of mismatched totals.

Step 2: Extract the day's financials

The owner needs revenue by transaction code, taxes, payments by method, advance deposits, city ledger (accounts receivable) movement, and guest ledger balances. On OPERA Cloud, that data is available through OHIP APIs and business events. On-premises, it usually comes from scheduled reports or file exports.

Step 3: Map to the owner's chart of accounts

OPERA transaction codes describe hotel activity: room revenue by segment, banquet food, minibar, parking, resort fee. The owner's ledger is organized differently, usually by entity, property, and USALI department (the Uniform System of Accounts for the Lodging Industry). A mapping table translates each transaction code to a general ledger account, department, and entity. That table is where most of the real work, and most of the errors, sit.

Step 4: Post a balanced journal entry

The mapped day becomes a balanced journal entry: revenue and tax liabilities on one side, cash, card clearing, guest ledger, and city ledger on the other. It posts to the right entity and period in Yardi, MRI, or M3, with a reference back to the OPERA business date.

Step 5: Reconcile cash and cards

Card processors settle days later and net of fees. Cash deposits are batched. The posted card clearing and cash accounts must match what actually reaches the bank, or differences pile up until month-end.

The five common failure points

Failure point	What goes wrong	How automation prevents it
Timing	Data pulled before the night audit finishes	Trigger on the business-date-closed event, not a clock time
Unmapped codes	A new transaction code is added at the hotel and posts nowhere	Block the posting and alert finance when an unmapped code appears
Out of balance	Rounding, voids, or adjustments leave debits ≠ credits	Validate the balance before posting; post nothing that doesn't balance
Duplicates	A day is posted twice after a retry or a re-run	Use the property and business date as a unique key
Settlement gaps	Card and cash postings never get matched to the bank	Reconcile clearing accounts daily against bank and processor data

How the integration works

An automated flow has three parts: the hotel source, an integration layer that maps and validates, and the owner's ledger.

Oracle OPERA to owner ledger · daily revenue posting with KriyaSync

OPERA Cloud hotels send their closed day through OHIP, and on-premises hotels through scheduled exports. KriyaSync maps, checks, and posts each day to the owner's ledger, reconciles card and cash against the bank, and sends anything it can't resolve to the finance team.

KriyaGo's approach: KriyaSync as the hospitality bridge

KriyaSync is KriyaGo's universal integration middleware for real estate. It already connects the systems property owners rely on, including Yardi, MRI, Procore, Sage, SAP Concur, and bank feeds. KriyaGo has delivered more than 100 integrations, including the full set of ERP integrations for Jones across roughly 2.5 billion square feet. For hotel owners, KriyaSync extends that same platform to the hospitality stack: Oracle OPERA and OHIP on the hotel side, and M3 where a management company keeps the hotel books.

What KriyaSync does in the daily posting

• Event-driven extraction.

On OPERA Cloud, KriyaSync uses OHIP APIs and business events to pick up each property's closed business day. For on-premises OPERA, it takes scheduled exports until the property moves to the cloud, so the owner-side process doesn't change at cutover.

• A managed mapping layer.

Transaction codes map to USALI departments, general ledger accounts, and entities in one maintained table per property or brand standard. New or unmapped codes stop the posting and alert finance, instead of disappearing.

• Validation before posting.

Every day is checked for balance, duplicates, and completeness before anything reaches the ledger.

• Posting to the owner's ledger.

Balanced daily journals post to Yardi, MRI, or M3, by entity and period, with the OPERA business date as the reference.

• Exceptions to people, with context.

When something fails, finance gets a clear message: which hotel, which date, and why.

Built for real estate finance, not just hotel operations

The difference with KriyaGo is where the data ends up. Most hospitality connectors stop at a hotel general ledger. Owners and investment managers need the next step: hotel results consolidated with the rest of the real estate portfolio, by fund, entity, and investor. Because KriyaSync already connects to real estate and investment platforms, the hotel's daily revenue lands in the same ledger the owner uses for every other asset. KriyaSync runs on Microsoft Azure, with a visual workflow layer built on n8n so changes to the posting logic can be made and tested quickly.

Optional: cash and reporting

Some owners extend the flow further. Bank and card settlement data can be reconciled against the posted clearing accounts, and daily flash results can be sent automatically to asset managers and investors. These extensions use the same KriyaGo platform, so there's no second integration project.

Who this is for

Daily OPERA-to-ledger automation pays off fastest for four kinds of owners.

Owner type	Typical setup	What automation changes
Hotel-owning REITs	Several hotels, each run by a third-party operator, reporting into a REIT ledger.	Daily, comparable revenue across operators, instead of waiting for monthly packages
Mixed-use owners	A hotel inside a portfolio of office, retail or residential assets on Yardi or MRI	The hotel lands in the same ledger and reports as every other asset.
Hotel investment funds and asset managers	Hotels held in funds with multiple investors and entities	Faster investor reporting and fund-level consolidation
Owner-operators with M3	The hotel books kept in M3, with owner reporting in a real estate platform.	One automated flow from OPERA through M3 to the owner's ledger

The common thread is that the people who need the numbers don't work in OPERA. They work in a real estate or investment ledger, and they want hotel results there without a manual step.

Implementation checklist

Use these steps to plan an OPERA-to-ledger integration, whether you're on OPERA Cloud already or planning the move from OPERA 5.

1. List every hotel and its stack.

Record each property's OPERA version (cloud or on-premises), operator, hotel accounting system, and the owner ledger it reports into.

2. Agree who owns the data.

Management agreements often decide who can access the PMS. Confirm in writing that the owner, or its integration partner, can receive daily financial data.

3. Set up OHIP access.

For OPERA Cloud properties, register the integration in OHIP and confirm which APIs and business events are licensed.

4. Build the mapping table first.

Export every active transaction code per property and map it to the USALI department, general ledger account, and entity. Agree on a brand or portfolio standard where you can.

5. Define the daily journal.

Decide the level of detail (summary or by department), the cut-off rules, and how taxes, deposits, and city ledger are handled.

6. Run in parallel for one month.

Post automatically to a test entity while the manual process continues. Compare daily and month-end totals.

7. Set exception rules.

Decide who gets alerted for unmapped codes, out-of-balance days, and missing business dates, and how quickly they must respond.

8. Add bank and card reconciliation.

Match clearing accounts to settlements daily so month-end doesn't start with a backlog.

9. Time it with the cloud migration.

For OPERA 5 hotels, build the owner-side flow once and switch the source from exports to OHIP at cutover.

10. Review mappings quarterly.

Hotels add outlets, packages, and fees. Keep the mapping table current.

Frequently asked questions

Not natively. OPERA is a hotel property management system, and Yardi and MRI are real estate platforms. An integration layer such as KriyaSync extracts the closed business day from OPERA, maps it to the owner's chart of accounts, and posts a balanced journal entry to Yardi or MRI.

OHIP is the Oracle Hospitality Integration Platform. It gives OPERA Cloud a self-service way to use APIs, subscribe to business events, register applications, and manage credentials. Its catalog includes a Back Office Operations API and data APIs covering finance subject areas.

OPERA 5.6, the last on-premises release, has Oracle Premier Support until December 2027, then moves to Sustaining Support. The software keeps running, but new fixes and certifications stop. Many owners are planning OPERA Cloud migrations now.

It's the accounting entry that records one business day at a hotel. It credits room, food and beverage, other revenue, and tax liabilities, and debits cash, card clearing, guest ledger, and city ledger. It's normally produced after the night audit closes the day in the PMS.

USALI is the Uniform System of Accounts for the Lodging Industry, the standard chart of accounts for hotel reporting. USALI mapping assigns each OPERA transaction code to a USALI department and to the owner's general ledger account, so hotel results are comparable across properties.

Yes. Where a management company keeps the hotel books in M3, KriyaSync can connect OPERA, M3, and the owner's real estate ledger, so results flow through to investor reporting.

It depends on the number of hotels, the OPERA version and how standardized transaction codes are. The mapping table and a one-month parallel run usually take longer than the technical connection.

The bottom line

Hotel owners shouldn't need a spreadsheet to see last night's revenue. With OPERA Cloud and OHIP, the data is available every day through APIs. With a mapping layer built for real estate finance, it can land in the same Yardi, MRI, or M3 ledger the owner already uses. For owners still on OPERA 5, the move to the cloud is the best time to rebuild the flow properly, once.

To see how KriyaSync connects Oracle OPERA to your real estate and investor accounting, talk to KriyaGo. For a broader view of the hotel tech stack, read Hospitality Tech Stack: Connecting Opera, M3 & Finance.

Get Started Now

SAP Concur Yardi & MRI Expense Integration | KriyaSync

Fri, 09 Oct 2026 14:50:17 -0400

The short answer

To connect SAP Concur Expense to Yardi Voyager or MRI Platform X, real estate firms use an integration layer that automates expense data flow, ensures approved reports are split by property, entity, and GL account, and then posts them into the ERP. This layer also manages intercompany entries when a property pays for costs on behalf of another entity, maintains synchronization of property, entity, and account lists, and routes reimbursement and card payment data appropriately. KriyaGo's middleware, KriyaSync, facilitates this process through KriyaGo Expense Connect, a partner app listed on the SAP Concur App Center.

Key takeaways

• Generic Concur connectors stop at the GL account.

Emphasizing property, entity, and other details ensures your expense data aligns with your real estate needs so that you can post with confidence.

• The hard part is allocation.

One expense report can touch several properties and legal entities, even when the corporate office pays the card bill.

• Two-way sync prevents rejections.

When properties, entities, and GL accounts flow from Yardi or MRI into Concur, employees can code only to valid values,

helping you stay in control and reducing manual correction.

• Proven in production.

Westwood Financial runs Concur with MRI, and Encore runs Concur with Yardi. Both connections are built and operated on KriyaSync.

Why Concur expenses are hard to post in real estate

SAP Concur Expense is widely used to capture travel, mileage, meals, supplies, and corporate card spend. In most industries, the accounting side is simple: an approved report becomes a journal entry by cost center and GL account. Real estate is different, for four reasons.

1. Every expense belongs to a property

A property manager's mileage, a site visit, the hardware-store run for a vacant unit: each belongs to a specific property, and often a specific unit or job. Yardi and MRI organize the books by property and entity, so an expense coded only to a department can't be posted correctly.

2. The payer and the owner are often different entities

Corporate cards are usually issued and paid by the management company or head office. The cost, though, belongs to the property-owning entity. That means every card expense charged to a property needs an intercompany entry: a receivable in the paying entity and a payable in the property entity. Done by hand, this is one of the most error-prone tasks in property accounting.

3. Recoverability matters

In commercial real estate, some property expenses can be recovered from tenants through CAM (common area maintenance) or other recovery pools, and some costs are charged back to a specific tenant. If the expense isn't tagged correctly when it's posted, it can be missed at CAM reconciliation time, and that's revenue left on the table.

4. Lists change constantly

Properties are acquired and sold. Entities are created. GL accounts and jobs open and close. If Concur's lists aren't kept in step with Yardi or MRI, employees code to values that no longer exist, and expense lines are rejected at posting.

What the manual process looks like

Without an integration, the usual workflow is: export Concur's accounting extract to a spreadsheet, have someone in accounting re-code each line by property and entity, add the intercompany entries, then import or key the results into Yardi or MRI. For a firm with hundreds of employees and properties, that's days of work every month. It also delays reimbursements and card reconciliations.

How a Concur-to-Yardi or MRI integration works

A well-built integration runs in two directions. Master data flows from the ERP into Concur, and approved expenses flow from Concur into the ERP.

SAP Concur Expense to Yardi or MRI · KriyaSync flow

Yardi or MRI sends its properties, entities, and GL accounts to Concur, so employees code against valid values. When a report is approved, KriyaSync maps, splits, and checks it, then posts property-level lines and intercompany entries to the ERP. Reimbursements go to an employee payable or payroll, and anything that can't be mapped goes to the accounting team.

Mapping Concur fields to Yardi and MRI

Most of the design work in a Concur integration is agreeing on which Concur field carries each piece of real estate coding. Proper mapping and exception handling ensure smooth processing, giving you confidence in data accuracy and reducing errors.

Concur Expense data	Yardi Voyager	MRI Platform X	Notes
Employee	Employee as payee (vendor record)	Employee as payee (vendor record)	Used for out-of-pocket reimbursements
Expense type	GL account	GL account	Mapped per expense type, with overrides by property type if needed
Custom field: property	Property	Building or entity	List synced from the ERP
Custom field: legal entity	Entity or book	Entity	Drives intercompany entries when it differs from the payer
Custom field: job or project	Job	Job	Optional, for capital or tenant-improvement work
Custom field: recoverable	Recovery or CAM coding	Recovery coding	Flags the cost for tenant recovery
Allocation percentages	One line per property	One line per entity	Splits one expense across several properties
Payment type (card or cash)	Card clearing or employee payable	Card clearing or employee payable	Separates card spend from reimbursements
Report ID and approval date	Reference and posting date	Reference and posting date	Traceability back to Concur
Receipt image	Attachment link	Attachment link	Optional, for audit support

Two rules make the mapping hold up over time. First, the lists flow one way, from the ERP into Concur, so the ERP stays the master. Second, any line that can't be mapped stops at a clear exception instead of posting to a suspense account.

KriyaSync for SAP Concur Expense

KriyaSync is KriyaGo's integration middleware for real estate. It has delivered more than 100 integrations across Yardi, MRI, Procore, Sage, and other systems, including the full set of ERP integrations for Jones across roughly 2.5 billion square feet. For SAP Concur, KriyaGo is a Concur Certified Partner, and its expense integration is listed on the SAP Concur App Center as KriyaGo Expense Connect.

What KriyaGo Expense Connect does

According to the App Center listing, KriyaGo Expense Connect supports Concur Expense Standard and Concur Expense Professional, and is available in North America, Europe, the Middle East, Africa, and Asia Pacific. Its real estate capabilities include:

• Property and entity distribution.

Expenses are distributed to multiple properties or legal entities, "even if the corporate office pays the expense."

• Intercompany entries.

Balanced due-to and due-from entries are created automatically when the payer and the property owner differ.

• Tenant expense chargebacks.

Costs that belong to a tenant are tagged so they can be billed back.

• Corporate card statement distribution.

Each card statement is split by property, so every property's share lands in its own books.

• Payroll reimbursements.

Reimbursements can be initiated through payroll, with the matching ERP accounting entries.

• Real-time data flow.

Lists and postings move between Concur and the ERP as they change, not in month-end batches.

The listing names Yardi Voyager and MRI Platform X among the supported ERPs, along with Procore, Microsoft Dynamics 365, Zoho One, ADP, and others.

How KriyaSync handles the flow

• Master data sync, ERP to Concur.

Properties, entities, GL accounts, and jobs are pushed from Yardi or MRI into Concur's lists, so coding is valid before a report is submitted.

• Approved reports: Concur to ERP.

Once a report is approved, KriyaSync picks it up, applies the mapping and allocation rules, and posts to Yardi or MRI.

• Validation first.

Every batch is checked for balance, unmapped values, and duplicates before posting.

• Exceptions with context.

Anything that fails goes to the accounting team with the report ID, line, and reason.

• Built on Microsoft Azure,

with a visual workflow layer built on n8n, so allocation and posting rules can be changed and tested quickly.

Implementation by Assetsoft

Implementation consulting is provided by Assetsoft, KriyaGo's sister company and a Yardi and MRI consulting firm. So the people configuring the integration also understand the property accounting on the other side of it.

Client examples

Westwood Financial: SAP Concur and MRI

Westwood Financial is one of the largest privately held retail real estate investment firms in the United States. Founded in 1970 and headquartered in Los Angeles, it owns and operates more than 125 shopping centers across 15 states.

Westwood runs its property accounting on MRI Software and its employee spend on SAP Concur. KriyaSync connects the two, so expenses coded in Concur post to the right shopping center and entity in MRI without re-keying. The same KriyaSync platform also links Westwood's wider payables workflow across MRI, Concur, and AvidXchange.

Encore: SAP Concur and Yardi

Encore, a real estate group based in Dallas, runs Yardi Voyager as its system of record and uses SAP Concur Expense for employee spend. KriyaSync connects Concur Expense to Yardi as part of a wider integration program that also links facilities, expense, and vendor systems into a single source of truth.

With expense data flowing into Yardi automatically, Encore reported about 75% faster processing compared with the manual workflow.

What both have in common

	Westwood Financial	Encore
ERP	MRI Software	Yardi Voyager
Concur product	SAP Concur Expense	SAP Concur Expense
Integration layer	KriyaSync	KriyaSync
Asset focus	Grocery-anchored and service-oriented shopping centers	Multi-property real estate
Result	Concur expenses post directly to MRI by center and entity	About 75% faster processing

Implementation by Assetsoft

Use these steps to plan a Concur Expense integration with Yardi or MRI.

1. Confirm your Concur edition.

Check whether you run Concur Expense Standard or Professional, and which custom fields and connected lists are available.

2. Decide the coding model.

Agree on which Concur fields carry property, entity, job, and recoverability, and whether allocations are allowed on every expense type.

3. Make the ERP the master.

Set up the list sync from Yardi or MRI into Concur for properties, entities, GL accounts, and jobs, and agree on how often it runs.

4. Map expense types to GL accounts.

Build one mapping table, with overrides by property type only where you need them.

5. Define the intercompany rules.

Document which entity pays each card program, which due-to and due-from accounts apply, and how reimbursements are paid.

6. Separate card spend from reimbursements.

Card transactions post to a card clearing account. Out-of-pocket expenses post to an employee payable or flow to payroll.

7. Set exception handling.

Decide who is notified about unmapped values, closed properties, or out-of-balance batches, and how quickly they respond.

8. Run a parallel month.

Post to a test database while the manual process continues, and compare totals by property and entity.

9. Train approvers on coding.

Most rejected lines come from wrong property or entity coding at submission, not from the integration.

10. Review quarterly.

Add new properties, retire sold ones, and refresh mappings as your portfolio changes.

Frequently asked questions

Not natively. Concur and Yardi Voyager need an integration layer between them. KriyaGo's KriyaSync connects Concur Expense to Yardi through KriyaGo Expense Connect, a partner app on the SAP Concur App Center.

Yes, through an integration partner. KriyaGo Expense Connect supports MRI Platform X, and Westwood Financial uses KriyaSync to connect Concur with MRI.

Use Concur's allocation feature with a property field that's synced from the ERP. The integration then creates one posting line per property, and adds intercompany entries when the paying entity differs from the property-owning entity.

Card transactions post to a card clearing account in the paying entity and are distributed to each property's books. KriyaGo Expense Connect distributes corporate card statements by property automatically.

It's KriyaGo's SAP Concur App Center listing for Concur Expense Standard and Professional. It connects Concur to real estate ERPs including Yardi Voyager and MRI Platform X, with property and entity distribution, intercompany entries, tenant chargebacks, card statement distribution, and payroll reimbursement.

Yes, if they're tagged at submission. A recoverable or chargeback field in Concur carries the flag into Yardi or MRI, so the cost is included in CAM recovery or billed to the tenant.

It depends on the number of entities, card programs, and custom fields. Agreeing on the coding model and the intercompany rules usually takes longer than the technical connection.

The bottom line

SAP Concur excels at capturing employee spend, and Yardi and MRI excel at property accounting. The gap between them is real estate coding: property, entity, intercompany, and recoverability. A purpose-built integration closes that gap, so approved expenses land in the right property's books, card statements reconcile by property, and employees are reimbursed faster.

To see how KriyaSync connects SAP Concur Expense to Yardi or MRI, book a demo with KriyaGo or visit our SAP Concur integration page.

Get Started Now