How to keep records in 1C: data model, controls and period close

Working answer

For “How to keep records in 1C: data model, controls and period close”, define the outcome as a change in management practice. The central object is intercompany transactions; it needs an agreed source, decision owner and observable state after the action “align identifiers and master data”.

The first evidence is not a solution presentation but a reproducible example of “budget versions are not comparable”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

How to organise accounting in 1C in practice

The answer to “how to keep records in 1C” starts with the accounting model, not with entering the first document. Define legal entities and business units, accounts and analytical dimensions, recognition rules, master-data owners, the closing calendar and control reports.

After configuration, test the full cycle: source document, transaction posting, register entry, reconciliation, correction and reporting. For management accounting, separately agree how financial measures relate to responsibility centres, contracts, projects and sources of actuals.

• Document the accounting policy and mandatory analytical dimensions.
• Assign master-data owners and change rules.
• Test period close using a controlled document sample.
• Reconcile the report with source documents and calculation rules.

Process and data boundary

The subject model starts with two reference objects: contracts, commitments and payments and intercompany transactions. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “maintain lineage and versions”.

The primary boundary is contracts, commitments and payments. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Record 1. Object: Financial responsibility centres. Required details: identifier, lineage, quality rule and update event. Signal: A payment cannot be traced to its commitment.
• Control record 2. Object: Budgets and scenarios. Observable signal: Close depends on manual files. Accountability: semantic owner and quality owner.
• Boundary 3. Object: Contracts, commitments and payments. Define the source, frequency, permitted transformations and response to “budget versions are not comparable”.

Events, data and exchange

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is intercompany transactions.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “budget versions are not comparable”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Subject area 5: Consolidation and management reports. Verification basis: system of record, owner authority and the signal “measures use different calculation rules”.
• Object 4: Intercompany transactions. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Eliminations have no owner.
• Boundary 3. Object: Contracts, commitments and payments. Define the source, frequency, permitted transformations and response to “budget versions are not comparable”.

Accountability boundary

The article addresses “How to keep records in 1C: data model, controls and period close”. The adjacent management issue is data model, controls and period close. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “measures use different calculation rules”, the material risk is “promising an effect without a baseline model”, and the testable action is “maintain lineage and versions”. This chain turns a broad term into a concrete decision.

• Decision 1: object — financial responsibility centres; signal — close depends on manual files; action — align identifiers and master data.
• Decision 2: object — budgets and scenarios; signal — budget versions are not comparable; action — define checks and corrections.
• Decision 3: object — contracts, commitments and payments; signal — eliminations have no owner; action — maintain lineage and versions.

Quality and correction rules

The method is a sequence of decisions rather than a universal checklist. For intercompany transactions, each output is used at the next step: the model supports the scenario, the scenario defines data and requirements, and requirements become test and acceptance criteria.

For contracts, commitments and payments, the sequence may change with scale and constraints, but assumptions are always documented. When source data is incomplete or a decision involves an external party, the dependency receives an owner, review date and condition for proceeding. The first action is “align identifiers and master data”.

• Decision 1: identify key objects. The basis for the next step is budgets and scenarios.
• Step 2. Assign systems of record. Output: contracts, commitments and payments.
• Align identifiers and master data is the action at stage 3. The output documents intercompany transactions.
• At position 4, the action is “define checks and corrections”; its result is consolidation and management reports.

Signals in the starting situation

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: budget versions are not comparable. It should be supported by a real example such as a document, data sample, decision record or registered variance.

The first scope is limited to one object and one decision. Changing every process, master-data set and system at once obscures causality. For the signal “measures use different calculation rules”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Diagnosis records “measures use different calculation rules”, its recurrence and its impact on budgets and scenarios.
• Observation 2: A payment cannot be traced to its commitment. Required fields: frequency, source and consequence for contracts, commitments and payments.
• Signal: Close depends on manual files. Evidence includes an example, frequency and consequence for intercompany transactions.

Who makes the decision

Build the authority matrix around decisions concerning consolidation and management reports. Assign the right to change a rule, duty to prepare data, authority to approve an exception and accountability for confirming the outcome separately.

Define the escalation path for “align identifiers and master data” concerning consolidation and management reports in advance. The business owner is accountable for decision meaning, the data owner for evidence fitness, the architect for dependency integrity and the project manager for the agreed work sequence.

• In the decision matrix, business owner connects budgets and scenarios with the action “align identifiers and master data”.
• Architect: decision area — contracts, commitments and payments; control action — define checks and corrections.
• Data owner is accountable for intercompany transactions and confirms the action “maintain lineage and versions”.
• Role: Project manager. Decision object: consolidation and management reports; verified step: identify key objects.

Acceptance criteria

The acceptance criterion for consolidation and management reports includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “measures use different calculation rules”, passes through an authorised decision and “maintain lineage and versions”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Criterion 1. Object: Financial responsibility centres. Test fields: baseline, target change, source and owner. Signal: Budget versions are not comparable.
• 2. Acceptance object: budgets and scenarios; compare the baseline sample, expected change and confirmed actuals. Test signal: Eliminations have no owner.
• Evidence item 3 describes contracts, commitments and payments, comparable test conditions and the person accountable for interpretation. Signal: Measures use different calculation rules.
• Test 4 concerns intercompany transactions. The method, interpretation owner and outcome source are documented. Signal: A payment cannot be traced to its commitment.

What can distort the outcome

For the risk “promising an effect without a baseline model”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

An assumption concerning intercompany transactions remains valid only until its review event. If the source, scope or accountable role changes, update the decision boundary and repeat the affected test.

• Risk review starts with the condition “automating an unaligned financial model”. The decision uses the action “assign systems of record” and data about intercompany transactions.
• Risk record 2. Condition: Losing dimensions during consolidation. Control action: Align identifiers and master data. Evidence source: Consolidation and management reports.
• Risk: Duplicate commitment entry. Control: define checks and corrections. Evidence: financial responsibility centres.
• Risk condition 4: Comparing platforms without scenarios. Response: Maintain lineage and versions. Testable evidence: Budgets and scenarios.

Where to begin

The first session examines one real case involving contracts, commitments and payments. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “budget versions are not comparable”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “align identifiers and master data”; assign an additional test or stop condition to the risk “losing dimensions during consolidation”.

• Decision 1: identify key objects. The basis for the next step is budgets and scenarios.
• Step 2. Assign systems of record. Output: contracts, commitments and payments.
• Test 4 concerns intercompany transactions. The method, interpretation owner and outcome source are documented. Signal: A payment cannot be traced to its commitment.
• Control record 5: Consolidation and management reports; data version, calculation rule, expected change and actual outcome. Signal: Close depends on manual files.