# Payroll to accounting: a journal today, an ERP integration that is ready but not live Continuing the Meridian Interiors story: once a month's payroll is approved, the numbers have to reach the company's books. This page says plainly what BlueOneHR does for that today, and what is integration-ready but **not live**: no Tally, TallyPrime or Microsoft Dynamics 365 system is connected, reached or synchronised by anything described here. *Illustrative demonstration prepared using publicly available company context and synthetic data. This page does not represent a production deployment, customer endorsement, or use of real employee data.*

Payroll to accounting: a journal today, a Tally and Dynamics integration that

## The status in one line **Integration-ready, not live provider execution.** The Finance journal and its CSV export are real and usable today. The ERP integration layer behind them exists and is exercised only against mock endpoints that simulate Tally and Dynamics 365. Every record that layer writes is labelled **MOCK**, and nothing in this workspace can label it otherwise. ## What is real today: a balanced journal and a CSV export Go to **Payroll → Finance**. **Finance & Accounting** lists the journal entries generated for the company, with the **Type**, **Period**, **Status**, **Debit**, **Credit** and whether the entry is **Balanced**. Entries are generated from an approved **Payroll Register** run (or from a finalized **Compliance** run for the statutory employer cost); they are not typed in by hand. Select **View** on an entry. A payroll journal for an approved run has: - **Salary Expense** on the debit side, for the month's gross pay; - **Salary Payable** on the credit side, for net pay; - **Payroll Deductions Suspense** on the credit side, for the month's deductions. The page shows the **Total** of each side. An entry that does not balance cannot be posted. A draft entry can be **Posted**, after which it is read-only. The account names are the company's own **Account Mapping**, which an administrator can change. **Download CSV** exports the entry. The page says in its own words that the entry does not post to any live accounting system: you download the CSV and import it into yours, or use it as a reference for a manual journal entry. That is the supported route to accounting today. The **Integrations** page covers workspace apps and inventory sync. It has no screen for an ERP connection. ## What is integration-ready: the layer behind the journal BlueOneHR contains an ERP integration layer for two systems, built and tested against mock endpoints only. In order: 1. **Payroll event.** An approved payroll run produces a posted, balanced journal. Only posted, balanced journals can go into a batch. If any journal in a batch is unbalanced, the whole batch is refused. 2. **Batch and approval.** The journals of one period become a draft batch. The batch goes through the company's **ERP Sync Batch** approval chain, and the person who built the batch cannot approve it. 3. **Adapter.** An adapter translates the approved batch for the target system: for **Tally**, a Journal voucher in the XML that TallyPrime imports; for **Dynamics 365 Finance**, a journal post. 4. **Mapping.** Each journal line's account name, taken from the company's **Account Mapping**, goes across as the ledger name in the target system, and each journal carries a stable reference that the target system can match on. The ledger must already exist in the target system. 5. **Acknowledgement.** Each reply is recorded as **acknowledged**, **partial**, **failed** or **unknown**. Failures are classified (for example authentication, rate limiting, a missing ledger or an unbalanced voucher). 6. **Reconciliation.** BlueOneHR compares what it sent with what the target system acknowledged. A match marks the batch **reconciled**. A mismatch produces a report and the batch is not marked reconciled. Two rules are worth knowing because they decide how failures behave: - If a reply is lost after the target system may have accepted a voucher, the batch becomes **unknown**. It is resolved by asking the target system for its status, and the batch is **never** sent again blindly. - A retry sends only the items that failed, and records a new attempt rather than overwriting the old one. Every step writes an audit record, and every record carries the **MOCK** label. The integration layer is switched off by default on an instance, so a production instance cannot send anything to a simulator by accident. ## Not confirmed - **No real Tally, TallyPrime or Dynamics 365 system has been reached.** Nothing has been imported into, posted to or reconciled against a real ledger. The vouchers and journals described above are the format the adapters produce, checked against test fixtures. - Whether a re-sent voucher replaces the earlier one rather than creating a duplicate in a real TallyPrime company is not confirmed. - Ledger master validation and real authentication to Dynamics 365 (Microsoft Entra) are not confirmed. - There is no screen to create an ERP connection, list batches, approve a batch or see its reconciliation, and nothing is submitted on a schedule. Those steps are not available from the product's screens today. - Splitting payroll expense by branch cost centre for an ERP is opt-in per connection and rests on assumed accounting defaults that no accounting owner has confirmed. ## Related reading - [A first payroll run, reviewed and approved by someone else](https://docs.blueonehr.com/books/enterprise/page/a-first-payroll-run-reviewed-and-approved-by-someone-else) - [India payroll compliance: a monthly run and a governed correction](https://docs.blueonehr.com/books/enterprise/page/india-payroll-compliance-a-monthly-run-and-a-governed-correction) - [The connected HR lifecycle: hiring to workforce operations](https://docs.blueonehr.com/books/enterprise/page/the-connected-hr-lifecycle)