Sage Intacct Data Services: Beyond the Connector

How Roghnu turns Sage Intacct API objects into a finance-ready data model

Most Intacct integrations stop at the API. Tables land in your warehouse as one-to-one copies of API objects, and the work of turning them into something finance can use — joins, grains, account mappings, period logic, reconciliation — lands back on your team. Roghnu goes beyond the connector to curate a finance-oriented semantic layer of views, making it quicker and easier to report on your data and discern actionable insights.

The Connector Problem

A typical “Intacct connector” lands API objects in your warehouse exactly as the API returns them. You receive raw header and line tables—separate AP bill headers and bill items, separate invoice headers and invoice items, separate GL entries, batches, and journals—and the integration ends there.

Everything that makes that data usable is left to you:

• Joining headers to their line items every time a query touches AP, AR, POs, or SOs.

• Choosing the right grain for each report and keeping it consistent.

• Mapping Intacct account groups to your own P&L and balance sheet structure.

• Building a usable period calendar when source tables don’t carry one.

• Joining transactions to dimensions—location, department, class, item, etc.—over and over.

• Proving the warehouse still reconciles to Intacct as data flows through.

This isn’t a small amount of work, and it has to be done by every team that touches the data.

The Roghnu Semantic Layer

Roghnu maintains a managed data warehouse that holds Intacct-sourced data, and we expose business-friendly views, measures, and reports on top of it. These act as a semantic layer—the place where raw API tables become recognizable business objects.

Roghnu has developed a series of standardized views that bring related tables together to give a fuller picture of financial operations, thereby streamlining the reporting process. We also have views in our intacct_bi schema that are utilized in our standard Power BI report packages—executive, operations, projects, inventory, and data anomalies. Hundreds of DAX measures are built from these views, enabling advanced analysis and visualization. We can also develop customized views and reports that meet your specific needs.

An additional aspect of Roghnu’s semantic layer is the selection of prebuilt SQL SELECT statements that run in our Data Portal’s SQL Builder, making it easy for non-technical users to find the data they need in a fast and secure manner.

Inside the Layer

Header and line stitched entities

One pattern across Intacct’s data is two-table: a header and its lines. We stitch them at the view layer so consumers see a single business object. For example:

• AP Bills — APBILL joined to APBILLITEM

• AR Invoices — ARINVOICE joined to ARINVOICEITEM

• Purchase Orders — PODOCUMENT joined to PODOCUMENTENTRY

• Sales Orders — SODOCUMENT joined to SODOCUMENTENTRY

• GL Journals — GLENTRY joined to GLBATCH and GLJOURNAL

Header attributes (vendor, status, due date, currency, totals) and line attributes (account, amount, dimensions, quantity) arrive together.

Aging

Roghnu’s AR Aging and AP Aging views standardize key metrics such as outstanding balances, due dates, aging buckets, payment status, and customer/vendor dimensions, enabling users to analyze receivables and payables without needing to understand the underlying transactional complexity. By embedding this business logic directly into the semantic layer, Roghnu improves reporting accuracy, simplifies self-service analytics, and ensures stakeholders across finance and operations are working from a single, trusted source of truth.

Multiple reporting grains, on purpose

Every transactional domain ships in two grains so consumers pick the right shape for the question rather than re-grouping in SQL each time:

• _ALL views — full line-level detail, for drill-down and analytics

• _LIM views — summarized at the header grain, for balances and rollups

Same source data, two well-defined shapes. Fewer grain mistakes, fewer surprises.

A shared period calendar

CALENDAR_PERIOD_VW exposes month-end reporting periods with start and end dates. Any transaction table—even those that don’t carry a period directly—can be joined to a consistent period definition. One source of truth for “what does Q3 mean here.”

Configurable P&L mapping

Account group rollups belong to the business, not the integration. Two views handle this:

• ENUM_PNL_MAPPING — the configurable map from Intacct account groups to P&L lines

• PNL_REPORT — a ready P&L sliceable by vendor, customer, account, department, location, class, or item

Change the mapping; the report follows. The rule set is data, not code.

Reconciliation built in

Trust is part of the deliverable. Roghnu ships reconciliation views that continuously verify the warehouse against Intacct so customers don’t have to build their own data-quality probes.

• RECON_GLAB_TO_GLAB_SS — confirms the GL Account Balance semantic-layer view matches the raw table

• RECON_SETUP_GLAB_PERIODS_VALUE_CHECK — ties accounting-period setup to actual GLAB data

• RECON_ROWCOUNT_GLACCOUNTBALANCE & RECON_ROWCOUNT_GLDETAIL — transaction volume per period for anomaly detection

• RECON_GLACCOUNTBALANCE_SUMMARY — surfaces missing reporting periods against GLAB
  
  

Tool-aware delivery

Some views are shaped specifically for the tools finance teams already use. The *_VW_SS variants — for example GLACCOUNTBALANCE_VW_SS and GLBUDGETITEM_VW_SS — are tuned for Spreadsheet Server, so Excel-based reporting drops onto views that fit its expectations.

A Side-by-Side Example

“Get the last quarter of AP bills with vendor, due date, account, amount, department, and location.” Two architectures, two very different paths to the answer.

API-Only Connector	Roghnu Semantic Layer
Direct access to source-system API endpoints.	Business-ready views that combine and organize data across source tables.
Requires users to understand the source application's data model.	Uses finance and operational terminology familiar to business users.
Often requires multiple API calls and joins to answer a single business question.	Pre-joined datasets reduce complexity and accelerate reporting.
Raw source data with limited business context.	Business logic, calculations, and relationships are already applied.
Report development is typically slower and more technical.	Report development is faster and easier for analysts and end users.
Higher risk of inconsistent calculations across reports.	Standardized metrics help ensure consistency across reporting.
Best suited for developers and data engineers.	Designed for finance teams, analysts, and business users.

A Selection of What’s in the Layer

Representative views from the Roghnu catalog. The full inventory spans the General Ledger, AP, AR, Purchase and Sales Orders, Budgets, Calendar, API usage, and the configurable P&L reporting model.

Domain	View	What it gives you
Calendar	intacct.CALENDAR_PERIOD_VW	Month-end periods with start/end dates, joinable to any transaction stream.
General Ledger	QBTGLACCOUNTBALANCE_VW_SS	GL Account Balance shaped for Spreadsheet Server consumption.
General Ledger	STD_GL_M$_BAL_ALL__	GL balances enriched with locations and departments for dimensional slicing.
Journal Entries	JOURNAL	Combines GL entries, batches, and related fields into a finance-ready journal entry view.
Payables	AP_BILLS_LIM	AP bills with header attributes and line detail combined into a single row set.
Payables	AP_PAYMENT	AP payment activity for cash-management analysis.
Payables	VENDOR	Consolidated vendor history including bills, adjustments, payments, and unions across transactions.
Receivables	R_INVOICE	Invoice reporting view designed for flexible reporting and query needs.
Receivables	R_CUSTOMER	Customer master data and customer-based reporting dimensions.
Purchase Orders	PODOCUMENT	PO status, balances, and currency details in a single view.
Sales	Sales Views	Sales and revenue reporting views for operational analysis.
Reporting	ENUM_PNL_MAPPING	Configurable mapping from account groups to user-defined P&L structures.
Reporting	PNL_REPORT	P&L reporting by entity, class, item, and other dimensions.
Reconciliation	RECON_GLAB_TO_SS	Continuously confirms balances and surfaces differences automatically.
Validation	BLAQVIEW_VALIDATION	Cross-checks metrics against source data and summarizes results by period.
API	API_USAGE	API call volume by partner and day for operational visibility.

Conclusion

Roghnu’s approach recognizes that the value of financial data is not in simply extracting it from Sage Intacct, but in making it usable, trustworthy, and actionable. By building and maintaining a curated semantic layer on top of raw Intacct data, Roghnu removes much of the repetitive engineering and reconciliation work that finance and analytics teams would otherwise need to build themselves.

Instead of treating the integration as the finish line, Roghnu treats it as the foundation. The result is a finance-oriented data platform that accelerates reporting, improves consistency across teams, reduces technical overhead, and gives organizations greater confidence in the numbers they rely on to make decisions.

Have questions? We’d love to help. Set up a demo or send us a message to request more info.