WSS Accounting Concepts Guide

User Manual:

Open the PDF directly: View PDF .
Page Count: 70

Download
Open PDF In Browser	View PDF

www.wallstreetsystems.com

Wall Street Systems – Empowering Treasury Trade and Settlement

Wallstreet Suite
Accounting Module
WSS Accounting Concepts Guide
Version 7.3.14

Information in this document is subject to change without notice and does not represent a commitment on the part
of Wall Street Systems. The software and documentation, which includes information contained in any databases,
described in this document is furnished under a license agreement or nondisclosure agreement and may only be
used or copied in accordance with the terms of the agreement. It is against the law to copy the software or
documentation except as specially allowed in the license or nondisclosure agreement. No part of this publication
may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical,
photocopying, recording, or otherwise, without the prior written permission of Wall Street Systems.
Although Wall Street Systems has tested the software and reviewed the documentation, Wall Street Systems
makes herein no warranty or representation, either expressed or implied, with respect to software or
documentation, its quality, performance, marketability, or fitness for a particular purpose. As a result, this
software is provided "as is", and in no event will Wall Street Systems be liable for direct, indirect, special,
incidental, or consequential damages from any defect in the software or by virtue of providing this
documentation, even if advised of the possibility of such damages. The documentation may contain technical
inaccuracies and omissions.
The mention of an activity or instrument in this publication does not imply that all matters relating to that activity or
instrument are supported by Wallstreet Suite, nor does it imply that processing of or by that activity or instrument is
carried out in any particular way, even if such processing is customary in some or all parts of the industry.
The windows and screen images shown herein were obtained from prototypes during software development. The
actual windows and screen images in the software may differ.
© Copyright 2011 Wall Street Systems IPH AB. All rights reserved.
First Edition (April 2011)
This edition applies to Wallstreet Suite version 7.3.14 and to all later releases and versions until indicated in new
editions or Wall Street Systems communications. Make sure you are using the latest edition for the release level of
the Wall Street Systems product.

Wall Street Systems, WSS, WALLSTREET, WALLSTREET SUITE and the Wall Street Systems logos are
trademarks of Wall Street Systems Delaware, Inc.
Finance KIT, Trema and Trema logo are trademarks of Wall Street Systems Sweden AB.
Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
Adobe, Acrobat, and Acrobat Reader are either registered trademarks or trademarks of Adobe Systems
Incorporated in the United States and/or other countries.
All other products mentioned in this book may be trademarks or service marks of their respective companies or
organizations.
Company names, people names, and data used in examples are fictitious unless otherwise noted.

Contents

Preface .............................................................................................................................7
Associated documents .................................................................................................................. 7
Date format ..................................................................................................................................... 7
How to rotate pages in Acrobat Reader ....................................................................................... 7

1 Accounting architecture .............................................................................................9
1.1 Introduction ............................................................................................................................. 9

2 Bookkeeping types ...................................................................................................11
2.1 Introduction ........................................................................................................................... 11
2.2 RUNNING accounting ........................................................................................................... 11
2.2.1 Value date accounting from TRM ................................................................................... 11
2.2.2 Value date accounting from CMM ................................................................................... 12
2.2.3 Trade date accounting .................................................................................................... 13
2.2.4 Commercial loans accounting ......................................................................................... 14
2.3 OFF-BALANCE sheet accounting ........................................................................................ 14
2.4 CTB accounting ..................................................................................................................... 15
2.4.1 Cumulative CTB .............................................................................................................. 15
2.4.2 Periodic CTB ................................................................................................................... 16

3 Key accounting entities ............................................................................................19
3.1
3.2
3.3
3.4

Introduction ........................................................................................................................... 19
Ledger .................................................................................................................................... 19
Ledger groups ....................................................................................................................... 20
Account Types ...................................................................................................................... 20

4 Global accounting support ......................................................................................21
4.1 Introduction ........................................................................................................................... 21
4.2 Distributed versus centralized maintenance ...................................................................... 21
4.2.1 Distributed maintenance ................................................................................................. 21
4.2.2 Centralized maintenance ................................................................................................ 22
4.3 Ledger .................................................................................................................................... 22
4.3.1 Key rules ......................................................................................................................... 23
4.4 Chart and its extensions ...................................................................................................... 23
Accounting Module WSS Accounting Concepts Guide

4.5 Period set ............................................................................................................................... 24
4.6 Perspective ............................................................................................................................ 24
4.6.1 Key rules ......................................................................................................................... 25
4.7 Attribute overriding ............................................................................................................... 25

5 Accounting processing ............................................................................................27
5.1 TRM accounting pre-processing ......................................................................................... 27
5.2 CMM accounting pre-processing ........................................................................................ 27
5.3 ACM accounting entry processing ...................................................................................... 28
5.3.1 Accounting event takeover .............................................................................................. 28
5.3.2 Entries aggregation ......................................................................................................... 28
5.3.3 Mapping to accounts ....................................................................................................... 29
5.3.4 Grouping to vouchers ...................................................................................................... 29
5.3.5 Voucher finalizing ............................................................................................................ 29

6 Advanced accounting features ................................................................................31
6.1 Account balances revaluation ............................................................................................. 31
6.2 End of year accounting ........................................................................................................ 31
6.3 Zero sweeping ....................................................................................................................... 31
6.3.1 Introduction ..................................................................................................................... 31
6.3.2 Transaction zero-sweeping ............................................................................................. 31
6.3.3 Account zero-sweeping ................................................................................................... 34
6.4 Time to maturity .................................................................................................................... 35
6.5 Open Item Accounting .......................................................................................................... 36
6.6 Cost centers and projects .................................................................................................... 37
6.7 Rebooking Accounting entries ............................................................................................ 37
6.8 Automatic Breakdowns ........................................................................................................ 37
6.8.1 Account Breakdown ........................................................................................................ 38
6.8.2 Cost Center Breakdown .................................................................................................. 38
6.8.3 Project Breakdown .......................................................................................................... 38
6.9 counterparty code ................................................................................................................. 38
6.10 Mapping events to entries .................................................................................................. 39

7 Accounting entry manager .......................................................................................41
7.1 Introduction ........................................................................................................................... 41

8 ERP interface .............................................................................................................43
8.1 Introduction ........................................................................................................................... 43
8.2 The ERP interface overview ................................................................................................. 43
8.2.1 ERP target ...................................................................................................................... 43
8.2.2 ERP target types ............................................................................................................. 43

8.2.2.1 SAP_FI ................................................................................................................. 44
8.2.2.2 FILE ...................................................................................................................... 44
8.2.3 ERP export modes .......................................................................................................... 44
8.2.3.1 VOUCHER export mode ....................................................................................... 44
8.2.3.2 ACCOUNT export mode ....................................................................................... 44
8.2.4 ERP target states ............................................................................................................ 45
8.2.5 ERP document ................................................................................................................ 46

9 Accounting reports ...................................................................................................47
9.1 Introduction ........................................................................................................................... 47
9.2 Set-up data reports ............................................................................................................... 47
9.3 Verification reports ............................................................................................................... 47

10 Viewing accounting balances ................................................................................49
10.1 Balances granularity ........................................................................................................... 49
10.1.1 Introduction ................................................................................................................... 49
10.1.2 Fixed balances .............................................................................................................. 50
10.1.2.1 Dimensions ......................................................................................................... 50
10.1.2.2 Configuration ...................................................................................................... 50
10.1.2.3 Reflection in activities ......................................................................................... 50
10.1.2.4 Reflection in ERP export by balances ................................................................ 50
10.1.2.5 Balances life cycle .............................................................................................. 51
10.1.2.6 Where visible ...................................................................................................... 51
10.1.3 Flexible balances .......................................................................................................... 51
10.1.3.1 Dimensions ......................................................................................................... 51
10.1.3.2 Configuration ...................................................................................................... 51
10.1.3.3 Flexible Balance Dimensions ............................................................................. 51
10.1.3.4 Reflection in activities ......................................................................................... 52
10.1.3.5 Reflection in ERP export by balances ................................................................ 52
10.1.3.6 Balances life cycle .............................................................................................. 52
10.1.3.7 Where visible ...................................................................................................... 53
10.1.4 Trade level balances ..................................................................................................... 53
10.1.4.1 Dimensions ......................................................................................................... 53
10.1.4.2 Configuration ...................................................................................................... 55
10.1.4.3 Reflection in activities ......................................................................................... 55
10.1.4.4 Reflection in ERP export by balances ................................................................ 55
10.1.4.5 Balances life cycle .............................................................................................. 55
10.1.4.6 Where visible ...................................................................................................... 56
10.2 Balances figures ................................................................................................................. 56
10.3 Ways for viewing the balances .......................................................................................... 57

11 Hedge accounting ...................................................................................................61
11.0.1 Legislation ..................................................................................................................... 61
11.0.2 Glossary ........................................................................................................................ 61
11.1 Solution coverage ............................................................................................................... 62
Accounting Module WSS Accounting Concepts Guide

11.1.1 Supported hedge risks .................................................................................................. 62
11.1.2 Supported IRS hedging methods .................................................................................. 62
11.1.3 Supported effectiveness tests ....................................................................................... 63
11.1.4 Supported effectiveness test methods .......................................................................... 64
11.1.5 Supported hedge types ................................................................................................. 66
11.1.6 Supported discharge methods ...................................................................................... 68
11.2 Configuration and processing steps - OVERVIEW .......................................................... 69

Preface

Welcome to the Wallstreet Suite Accounting Concepts Guide. This guide describes accounting
concepts and accounting configuration possibilities supported by Wallstreet Suite. For details about
the particular feature configurations you must follow to the particular recommended guides. In other
words, this guide should tell what all accounting related you can configure in the Wallstreet Suite,
but it does not tell you how to configure it. Detail configuraiton is described in the modules’
particular user guides.

Associated documents
Associated documents can be accessed from the Help menu of the Wallstreet Suite’s applications:

•

TRM User Guide

•

ACM User Guide.

Date format
All dates in this book, if not stated otherwise, are in format dd/MM/yyyy.

How to rotate pages in Acrobat Reader
Some pages in this book may have graphics rotated so that they can fit on the page. To see these
pages normally on your computer monitor, use the View - Rotate View menu option in Acrobat
Reader, or the equivalent keyboard shortcuts: Shift+Ctrl+Plus keys and Shift+Ctrl+Minus keys.

Accounting Module WSS Accounting Concepts Guide

Chapter 1

Accounting architecture

1.1 Introduction
Wallstreet Suite accounting framework allows a maximum flexibility and allows coping with multiple
accounting standards. The overall framework is shown on the picture below:

The accounting interface between TRM and ACM as well as the interface between CMM and ACM is
based on accounting events. Accounting event is a standardized structure of accounting data
generated by TRM and CMM (TRM accounting event is different from the CMM event) containing all
necessary information for processing in ACM. Accounting events in TRM are generated from
Accounting Inputs. Accounting events are generated by running the appropriate (TRM or CMM, CTB
or Daily) Events Generation activity.
Accounting events are taken over by ACM and they are transformed to accounting entries.
Accounting entry is an elementary accounting information in ACM, which is the subject of accounting
processing in ACM. The processing in ACM consists from several steps (event takeover, entries
aggregation, mapping to account, grouping to vouchers). All the ACM processing steps are
concentrated into one activity – Accounting Processing.

Accounting Module WSS Accounting Concepts Guide

1 Accounting architecture
1.1 Introduction

Chapter 2

Bookkeeping types

2.1 Introduction
Wallstreet Suite distinguishes between 3 basic bookkeeping types:

•

RUNNING accounting

•

OFF-BALANCE sheet accounting

•

CTB accounting

2.2 RUNNING accounting
RUNNING accounting is the accounting of real cashflows and realized results and can be further
categorized to:

–

Value date accounting

–

Trade date accounting

–

Commercial loans accounting

Note: Only Value date accounting is applicable for TRM transactions as well as for CMM
transactions. All the other accountings are applicable for TRM transactions only.

2.2.1 Value date accounting from TRM
Value date accounting is a default accounting of real cashflows and realized results. The definitions
for trade date accounting and off-balance sheet accounting are just additions to the value date
accounting settings.
Accounting entry resulting from the TRM value date accounting has the following key characteristics,
which should be used for defining the accounting mapping rules:
Field name

Field value(s)

Bookkeeping Type

RUNNING

Entry Type

CASH or NON_CASH

Origin Group

TRM

Origin Entity

TRM-TRANSACTION

Event Type

VALUE-DATE

Comment

Tips for mapping rules definition:

•

You typically define CASH (entry type) rules per your bank accounts.

•

Rules for entry type NON_CASH are typically defined per cashflow types. You can use any other
information for detailing the mapping rules, e.g. instrument group, instrument, portfolio, etc.

Accounting Module WSS Accounting Concepts Guide

2 Bookkeeping types
2.2 RUNNING accounting

2.2.2 Value date accounting from CMM
CMM supports only value date accounting.
Accounting entry resulting from the CMM value date accounting has the following key
characteristics, which should be used for defining the accounting mapping rules:
Field name

Field value(s)

Bookkeeping Type

RUNNING

Entry Type

CASH or NON_CASH

Origin Group

CMM

Origin Entity

CASH-RECORD or
BANK-TRANSACTION

Event Type

CMM-MANUAL-ENTRY or
VALUE-DATE

Reconciled (CMM Reconciliation)

YES or NO

If configured to YES, then the entry must have some
number in the CMM Reconciliation field.

View Type

CLIENT or BANK

CMM daily accounting entries are possible from two
View Types (a column visible in the Entry State Report
for entries originating in CMM). A view type in this
sense refers to weather the CMM Running entries represent a:

CMM State

CAPTURED, AUTHORIZED, RELEASED, RECONCILED

Comment

•

Client: An Account Holder whose CMM Cash
Record or Bank Transaction pays or receives an
Amount.

•

Bank: An IHB who is reflecting a Cash Record or
Bank Transaction movement on an account held by
one of its clients.

CMM State is empty for entry type NON_CASH
Depending on the configuration Cash entries from
CMM cash records are generated for the various states
a Cash Record is sent to, this includes:
•

Captured: Once a Cash Record is entered or
received in CMM

•

Authorized: Once a Cash Record is Authorized in
CMM

•

Released: Once a Cash Record is Released (i.e. to
an external Bank) in CMM

•

Reconciled: Once a Cash Record is Reconciled
with a bank Transaction

Entering and Shifting a Cash Record can be reflected by various suspense accounts until a cash
record is finally reconciled with an actual bank transaction. Events from CMM can originate from
CMM (directly) or from TRM (TRM via CMM)
In the case where CMM events have originated directly in CMM (Per Cash Record and View Type),
ACM will pull one Non-Cash Entry (an amount posted to a G/L account to represent the Balance
sheet purpose of the Cash Record). It will then receive a series of Cash Entries for the various states
through which a Cash Record is shifted. Finally, once a Cash Record is reconciled with a Bank
transaction, entries are received for the previous Cash Record state (to clear the previous suspense
entry) along with entries for each Bank Transaction (to be posted to an account representing the
"actual" Bank Account at the Financial Institution).
For example, a cash Record is sent from CMM representing a fee paid for services and CMM is
configured to post entries in states Authorized and State Reconciled (only). The following happens:

–

'When the cash record in CMM reaches state Authorized, the CMM events generations activity
will pull to ACM two entries.

2 Bookkeeping types
2.2 RUNNING accounting

–

A non-cash entry, which should use the appropriate criteria fields (i.e. instrument) to map to
an account representing "Fees paid for services".

–

And secondly, a cash entry in state Authorized, which should use the appropriate criteria
fields (I.e. Bank Account, CMM-State, etc.) to post to an account which represents a
payment in "Transit in state Authorized", "Not yet reconciled", or similar.

–

'When the cash record in CMM is reconciled with (a) Bank Transaction(s) it is in state
Reconciled, the CMM events generations activity will pull to ACM at least two new entries
(depending on how many Bank transactions where reconciled with the cash record).

–

The first cash entry in this set, (CMM state = Authorized) is used to clear the amount posted
prior to reconciliation. The initial rule which posted this amount to the suspense account is
sufficient and no additional rule is needed.

–

The additional entry (-ies) are generated from Bank Transaction(s). These should use the
appropriate criteria fields (i.e. Origin Entity, Bank Account, CMM-State Reconciled, etc.) to
post to account(s) which represents the actual bank account(s).

In the case where CMM events have originated in TRM (TRM via CMM) (per Cash Record and View
Type), the functionality is similar, however ACM will pull not pull a non-cash Entry (the assumption
is that this entry has already been posted as an entry originating in TRM). Only the Cash side of the
Entries for the various states which a Cash Record is shifted and final entries for the Bank
Transaction are received for TRM via CMM originating events.

2.2.3 Trade date accounting
The booking of the transactions on their trade date (transaction opening date) to a suspense
account and re-booking it from the suspense to a final balance sheet account is referred as Trade
Date Accounting. The trade booking in such way must be done for both cash and non-cash events.
This approach is called double-sided trade date accounting. A single-sided trade date accounting (a
possibility to book just a cash entry to a suspense account on trade date and re-booked from the
suspense account to a cash account on value date, while non-cash entry is booked to the respective
balance sheet account already on the trade date) is not supported.

Note: Wallstreet Suite distinguishes between Trade Date Accounting and Off-Balance Accounting.
For example, the booking of an FX forward deal on the opening date is referred as Trade
Date Accounting although some accountants may call it off-balance sheet accounting.
Off-Balance accounting in Wallstreet Suite is supported for swaps, options, FRAs, futures
and commercial loans.

Warning:

While off-balance accounting can be configured differently per result modes
(accounting standards), trade date accounting is either set or not set per all the
result modes at once. In other words: you cannot set trade date accounting just for
one result mode and not for the other one(s).

The trade date accounting events generation (as well as any other accounting events in the system)
can be configured to reflect specific needs of each client, for example, to configure it just for some
type of transactions.

Accounting Module WSS Accounting Concepts Guide

2 Bookkeeping types
2.3 OFF-BALANCE sheet accounting

Trade Date Accounting is a transaction-specific. The transaction must carry the attribute ‘Trade Date
Booking’ (shown in the Transaction Status column in Transaction Manager) in order to be booked on
trade date. There are two ways of assigning the ‘Trade Date Booking’ status to the transaction:
1. Manually in Transaction Manager, by running the Set Trade Date Booking command.

Warning:

If you assign the transaction status Trade Date Booking manually and you re-open a
transaction, be aware that this status is removed and you must assign it manually
again when shifting the transaction back to Final.

2. Automatically in Transaction Flow. Method DoTSetStatus allows you to automatically assign to a
transaction any status if the specified rule matches. In the default configuration, if the
‘TFLO-STATUS_TRADE-DATE-BOOKING’ rule matches the transaction then the transaction is
assigned Trade Date Booking status.
The trade date entry has Event Type = ‘TRADE-DATE’; it should be used for account mapping in the
Accounting Mapping Rule Editor.

Note: If a transaction is set for trade date booking, the TRADE-DATE reversing events on a

transaction value date are created regardless the generation of the initial TRADE-DATE
events on the transaction opening date, i.e. they are created even the events on the
opening date were not generated yet. This is given by the configuration of the accounting
event rules.

For a possibility of calculating and booking the FX results (e.g. between the trade date and the value
date) refer to the ACM Administration Guide (FX Conversion Rules).
Accounting entry resulting from the TRM trade date accounting has the same key characteristics as
the accounting entry from TRM value date accounting, only the event type is TRADE-DATE
accounting.

2.2.4 Commercial loans accounting
Wallstreet Suite supports the bookings of commercial loans.

2.3 OFF-BALANCE sheet accounting
Off-balance sheet accounting is the accounting based on off-balance accounting events.
Off-balance accounting in Wallstreet Suite is configured via the Accounting Configuration Editor. The
configuration in this editor drives for what instrument types and on what dates the off-balance sheet
accounting events in TRM are generated. Note that the off-balance sheet accounting events are
generated by running the TRM Daily Events Generation activity type.

Warning:

In some Wallstreet Suite installations you can see in the Activity Manager also the
End of Day Processing activity type. However, this activity type must not be used in
any relation with ACM! Only the TRM Daily Events Generation may be used with ACM
for the daily events generation in TRM.

Accounting entry resulting from the TRM off-balance sheet accounting has the following key
characteristics, which should be used for defining the accounting mapping rules:
Field name

Field value(s)

Bookkeeping Type

OFF-BALANCE

Comment

2 Bookkeeping types
2.4 CTB accounting

Field name

Field value(s)

Entry Type

OBS

Origin Group

TRM

Origin Entity

TRM-TRANSACTION

Entry Direction

Opening, Transfer, Closing.

Event Type

Comment

•

Opening: The first OBS entry for a particular transaction (generated either on the Opening Date or
Signature Date or Settlement Date.

•

Transfer: The OBS entry generated between the
opening and closing entry. The entry is generated
either on Signature Date or Settlement Date.

•

Closing: The OBS entry generated on the Maturity
Date of a transaction.

PROVISION, STANDARD,
MAXIMUM-AMOUNT

Off-balance accounting entries are technical entries with no direct link to cashflow(s), that is why no
cashflow specific information (e.g. cashflow type) is available for such entries.

2.4 CTB accounting
The booking of unrealized results in Wallstreet Suite is called Closing the Books (CTB). Unrealized
results are represented as key figures, for example, unrealized FX Gain/Loss, unrealized Accrued
Interest, etc.

Warning:

The CTB accounting can be run just after the execution of the RUNNING accounting
for a given CTB day!

Warning:

Automated CTB processing does not take into account any manual CTB adjustments
done via the Entry Manager, e.g. automatic CTB delta calculation in the case of CTB
periodic ignores any manual entries. If you still better do some adjustments, you
must reverse them manually at the moment of next CTB processing or to create
another adjustment.

ACM supports two basic types of CTB: cumulative and periodic.

2.4.1 Cumulative CTB
The whole unrealized result (key figure) is booked on a specified data (mostly the end of an
accounting period, e.g. end of month) and reversed before the posting of unrealized results next
time. The reversing entries must be booked as latest on the next CTB date and earliest 1 day after
the booking of the initial entries.
There are three ways, how to define, when the reversing CTB entry should be booked.

Accounting Module WSS Accounting Concepts Guide

2 Bookkeeping types
2.4 CTB accounting

Cumulative CTB - example
Posting of unrealized results at the end of each calendar month. Reversals are posted on the first
day of a next month; closing key figure values are listed in the table below.
Accrued interest - M-to-M result total value in EUR total value in EUR
31/1/2005

+10,000

+1,000

28/2/2005

+19,000

+600

31/3/2005

+29,000

-200

The following picture shows the posted CTB entries (just P&L accounts, i.e. just half of the
vouchers):

Note: ACM-SAME-SIDE-REVERSAL ledger property does not affect CTB reversing entries, i.e.
they are always posted on the opposite side of the account than the initial entries.

There are three ways of reversing CTB entries of cumulative type:
1. By specifying CTB Reverse Date in Accounting Processing activity.
2. By running a specific Reverse CTB activity.
3. If running CTB processing for next period (date), all previous not yet reversed CTB entries of a
cumulative type are reversed automatically.

Note: CTB Periodic entries are automatically reversed by the next run of CTB after the

transaction maturity date. If transaction maturity date is the same with the CTB date, the
CTB periodic entries are reversed on this date.

2.4.2 Periodic CTB
Just the changes between the current and previous unrealized results are posted.

Periodic CTB - Example
Posting of unrealized results at the end of each calendar month; closing key figure values are listed
in the table below including the monthly changes.
Accrued interest - Accrued interest total value in EUR change in EUR

M-to-M result M-to-M result total value in EUR change in EUR

31/1/2005

+10,000

+1,000

28/2/2005

+19,000

+9,000

+600

-400

31/3/2005

+29,000

+10,000

-200

-800

2 Bookkeeping types
2.4 CTB accounting

The following picture shows the posted CTB entries (just P&L accounts, i.e. just half of the
vouchers):

Note: The booking of CTB periodic entries can be modified by using the Transaction ZeroSweeping functionality.

Warning:

Whether you select the cumulative or the periodic CTB type, a total unrealized result
is reversed at the latest on the next CTB processing after a transaction maturity date.

Accounting Module WSS Accounting Concepts Guide

2 Bookkeeping types
2.4 CTB accounting

Chapter 3

Key accounting entities

3.1 Introduction
This chapter describes the basic entities used in the Wallstreet Suite accounting solution.

3.2 Ledger
A ledger represents an accounting book of a portfolio owner. It contains transactional accounting
data such as vouchers, accounting entries, and balances.
A Ledger is the combination of the following four entities (all mandatory):

•

Portfolio Owner

•

Chart

•

Period Set

•

Result Mode.

Chart, Period Set, and Result Mode are defined separately and can be used in different
combinations/ledgers to allow high flexibility and reuse ability.

Note: Once a ledger is defined, it is not possible to change any of its key entities: Owner, Chart,
Period Set, Booking Currency, Classification Group.

Warning:

The change of the bookkeeping currency is not supported.

An Accounting Event coming from TRM carries Owner and Result Method to allow for further
processing. Based on this information, a Ledger is identified. Each Ledger contains its own set of
Accounting Entries.
Rules for the definition of Ledgers are summarized below:

•

The number of Ledgers is unlimited.

•

One ACM owner can have multiple Ledgers.

•

Ledgers can be grouped in Ledger Groups (allows performing some accounting activities for
multiple Ledgers).

•

Each Ledger contains bookings according to a particular accounting standard (represented by
the Result Mode).

•

Each Ledger uses one particular Chart.

•

A Chart may be used by multiple Ledgers (for example, when the account structure is common
to more ACM users).

•

Period Opening/Closing is performed for a particular Ledger.

•

Once a Ledger is defined, it cannot be modified. A change to any Ledger component would have
a non-reconcilable impact on the accounting entries booked into the Ledger.

Accounting Module WSS Accounting Concepts Guide

3 Key accounting entities
3.3 Ledger groups

•

Accounting data (entries, vouchers, etc.) belong to a Ledger.

•

Detailed reporting is run for a particular Ledger and/or Ledger Groups in ACM.

•

ACM activities are run typically for a Ledger and/or Ledger Groups.

•

Period Opening/Closing is performed for a particular Ledger and/or Ledger Groups.

3.3 Ledger groups
Accounting Ledgers can be grouped to Ledger Groups. They can be used for two purposes:
1. as a starting parameter in most ACM activities; if you execute an activity for some ledger group,
the activity does its job for all the ledgers defined in the ledger group.
2. as a starting parameter in some reports showing the account balances; if you execute a balance
report for some ledger group, it shows the account balances aggregated from the balances for
the individual ledgers.

3.4 Account Types
ACM allows classifying the accounts by assigning the account types. They can be assigned to
accounts via the Account Editor. The account types can be used for:

•

Classification and maintenance the accounts within the chart of accounts

•

You can view the account balances per account types.

•

Many activities may be started per specified account type, e.g. Accounting End of Year, Time to
Maturity Processing, Account Zero Sweeping.

Account types are defined in the Account Type Editor

Chapter 4

Global accounting support

4.1 Introduction
The execution of parallel accounting in multinational corporations calls for the sophisticated handling
of accounting data – Global Accounting Support (GAS). GAS tries to address the following key
requirements:
1. Minimal maintenance effort of static data: that is, sharing of static data where feasible
2. Mapping and posting of parallel results to different accounts and periods
3. Clear responsibility split and transparency (for both static data and accounting entries).
These requirements are addressed in the Wallstreet Suite Global Accounting Support solution in
ACM. Key principals of the solution are:

•

The Ledger as an accounting book that is based on separately-defined all-important accounting
parameters

•

Creating distinct Accounting Entries per Ledger

•

Possibility of sharing charts, rules, periods, and other setups between the multiple ledgers

•

Possibility of extending centrally-defined Chart structure, accounts, and rules by individual local
owners (subsidiaries)

•

Possibility of booking to multiple Ledgers based on a single Chart (Centralized Maintenance)

•

Possibility of using different accounting periods for different accounting standards

•

Possibility of viewing only a restricted set of static data via Perspectives

•

Possibility of changing centrally-defined values of entities by individual local owners
(subsidiaries) using an Attribute Overriding mechanism.

This chapter describes key static data entities used in ACM with respect to GAS.

4.2 Distributed versus centralized maintenance
When considering sharing data (accounts, mapping rules, etc.) and keeping the
transparency/responsibility split in mind, there are several distinct key requirements:
1. Sharing between different standards (for example, IAS versus FAS)
2. Sharing between different variants of the same standard (for example, variants of the local
standard)
3. Strict responsibility split for maintenance of different standards and/or for individual local
standard variances
There are two ways of using accounting treatment in global operations: Distributed Maintenance and
Centralized Maintenance.

4.2.1 Distributed maintenance
Distributed Maintenance is a configuration to fulfill the requirements of a large international group
with many subsidiaries: each subsidiary reporting in both group and local standards (other standards

Accounting Module WSS Accounting Concepts Guide

4 Global accounting support
4.3 Ledger

are also possible). This corporation wishes to address points 1) and 2) above: to allow for separate

safe maintenance of individual standards, but also to allow for controlled management of variants in
local standards:

•

Group Standard (for example IFRS):

–

Standard is identical for all subsidiaries of the group.

–

Static data (accounts, rules, etc.) maintained by the group.

–

Summary of group results is based on such a standard.

Local standard (given by subsidiary country origin):

–

Can be either specific to subsidiary or common to several subsidiaries (owners).

–

Maintained either locally or in sub-groups by accounting standard.

–

Detailed individual account structure is usually derived from the common structure valid for
the relevant accounting standard.

Requirements addressed:

•

Clear responsibility split and transparency

•

Sharing for variances between (many) subsidiaries in one (local) standard

•

Sharing of static data between different accounting standards is not so important since it is
maintained by different people.

4.2.2 Centralized maintenance
Centralized Maintenance is a configuration to fulfill the requirements of a large company listed on a
foreign stock exchange and thus obliged to report in the local accounting standard and also in the
accounting standard of the stock exchange’s country. This company wishes to address point 1)
above, to allow for simple maintenance by a single group of people:

•

Local standard

–
•

Static data (accounts, rules, etc.) maintained by one group of people in the company

Standard of the country of the foreign stock exchange

–

Static data (accounts, rules, etc.) maintained by the same group of people as the local
standard

–

Intention to minimize the effort required to maintain the ‘secondary’ standard; tendency to
keep just exceptions/differences from the local standard.

Requirements addressed:

•

Sharing static data (accounts, rules) between different accounting standards

•

Responsibility split is not an issue since the same people manage both standards

Note: Since requirements are often contradictory, features for each type of use cannot be freely
mixed: the client installing the system has to evaluate carefully which approach is more
appropriate in individual cases.

4.3 Ledger
A Ledger represents an accounting book of an ACM owner. It contains transactional accounting data
such as vouchers, accounting entries, and balances.
A Ledger is the combination of the following four entities (they all are mandatory):

•

Owner

4 Global accounting support
4.4 Chart and its extensions

Portfolio owner with defined basic accounting characteristics: for example, rate scenarios for
realized and unrealized results.

•

Chart
Account structure with individual accounts and mapping rules.

•

Period Set
Fiscal year definition including special periods.

•

Result Mode
Results calculation definition.

Chart, Period Set, and Result Mode are defined separately and can be used in different
combinations/ledgers to allow high flexibility and reuseability.

Note: Once a ledger is defined, it is not possible to change any of its key entities: Owner, Chart,
Period Set, Booking Currency, Classification Group.

4.3.1 Key rules
•

The number of Ledgers is not limited.

•

One ACM owner can have multiple Ledgers.

•

Ledgers can be grouped in Ledger Groups (allows performing some accounting activities for
multiple Ledgers).

•

Each Ledger contains bookings according to a particular accounting standard (represented by
the Result Mode).

•

Each Ledger uses one particular Chart.

•

A Chart may be used by multiple Ledgers (for example, when the account structure is common
to more ACM users).

•

Period Opening/Closing is performed for a particular Ledger.

•

Once a Ledger is defined, it cannot be modified. A change to any Ledger component would have
a non-reconcilable impact on the accounting entries booked into the Ledger.

•

Accounting data (entries, vouchers, etc.) belong to a Ledger.

•

Detailed reporting is run for a particular Ledger and/or Ledger Groups in ACM.

•

ACM activities are run typically for a Ledger and/or Ledger Groups.

•

Period Opening/Closing is performed for a particular Ledger and/or Ledger Groups.

4.4 Chart and its extensions
Chart is an entity that consists of a definition of the structure and properties of accounts, mapping
rules, and voucher types.
Chart is an extensible entity. This means that an owner can create his/her own extension chart by
reusing (where permissions allow) an existing Chart (master chart), and adding some new
accounts and/or accounting rules. The goal of such a mechanism is:

•

Enforcing a common structure (master chart) while allowing different entities to create detailed
sub-accounts (extend the master chart) within their own extension chart.

Accounting Module WSS Accounting Concepts Guide

4 Global accounting support
4.5 Period set

•

Sharing of account structure (and other chart-dependent entities) where possible, to minimize
maintenance effort.

•

Defining clear responsibility for different parts of a Chart (possibility of a different domain for
each chart).

A chart contains all its own accounts and also all accounts from all its master charts (inherited
accounts). An account is always created in one specific chart.
The same concept is used also for Mapping Rules:

•

Mapping Rules maintained by a center are part of the Master Chart.

•

Individual Owners can define their own rules in their Extension Chart in order to use their local
accounts defined in the Extension Chart.

Chart-dependent entities are: Account, Account Type, Mapping Rule, Project, Cost Center and
Voucher Type. These entities belong to a chart. Each extension chart shares all the entities defined
in its master chart.

4.5 Period set
Period Set is an entity used for defining the fiscal year and its periods. It is an entity to which the
accounting periods belong (like Chart and its accounts). Period Set is defined as an independent
entity. Once defined, it can be used as a component of the Ledger.
The periods are open and closed by a Ledger and/or a Ledger Group.

4.6 Perspective
The permission management used in ACM is based on the same approach as used in TRM:

•

An ACM user can be assigned to zero, one, or more user groups.

•

Any kind of permission can be granted to a user or user group; the user inherits all permissions
from all user groups he/she belongs to.

•

The ACM static data access is controlled by the domain permissions (which is a subset of data to
manipulate with) and by the ACM object permissions (defines access to the individual ACM static
data editors).

•

ACM Ledger permissions define what type of activity, report, and/or voucher state is allowed for
a given user/user group within a Ledger (similar to the portfolio permissions based on allowed
users in TRM).

Key ACM entities are domain-dependent. They are:

•

Ledger

•

Ledger Group

•

Period Set

•

Chart

•

ACM Rule.

Period Set and Chart are the entities to which some other ACM entities belong to. The entities
dependent on either Period Set (only Accounting Periods) or Chart (Account Types, Accounts,
Mapping Rules, Voucher Types, Cost Centers, Projects, Grouping Rules, etc.) are domain-free, and
are maintained from the perspective of the key entity only.

4 Global accounting support
4.7 Attribute overriding

The domain permissions are inherited by these key entity-dependent entities via the key entities.
For example, if Period Set “1” belongs to a domain “A” and a user has permission for this domain,
the user can access the Accounting Periods defined for the Period Set “1” (depending on the object
permissions).
To avoid showing all accounts in the system when opening ACM Account Editor (depending on
allowed domains), ACM always shows the accounts for one chart only. The same applies for other
chart-dependent entities, and it also applies to the accounting periods (to avoid showing all periods
in the system, it restricts them to one period set only).
The restriction described above is handled via ACM Perspective. It consists of the following three
entities:

•

Chart

•

Period Set

•

Ledger.

When starting any ACM entity dependent either on chart and/or period set, the user is first asked to
select the perspective. Thus the editor opens just for a specific chart and/or period set.
As well as a filtering feature (possibility to work at one time with data belonging to only one chart or
period set), ACM Perspective provides a mechanism for extended control over access permissions. A
user can create only such perspectives for which he/she has access permission. For example, only
those charts are offered to which the user has a domain permission). All data that is outside the
selected perspective is hidden.
The user perspective is also used in connection with the attribute overriding mechanism.

4.6.1 Key rules
•

Perspectives are defined in ACM Perspective Editor.

•

Perspectives are stored per users.

•

One user can define an unlimited number of perspectives. A single perspective can be marked as
the default (appears as the first one in the selection list of perspectives when starting the
perspective-dependent editor).

•

Perspective-dependent editors can be opened in one user perspective at the same time only. For
example, if a user has opened editor A in perspective 1 and then opens editor B, the user is
prompted to open editor B in perspective 1 as well. If the user selects a different perspective for
editor B, then editor A is automatically switched to the same perspective.

4.7 Attribute overriding
The attribute overriding mechanism allows a user to set the attributes of an object (for example,
account, period, cost center, etc.) in a perspective either of an extension chart or a ledger.
The aim of this is to allow the flexible configuration of static data objects while preserving maximum
re-use of a previously-defined configuration, and compatibility with the chart extension mechanism.
An object can have several attributes. These attributes are edited typically by:

•

The object administrator

•

The privileged user.

The object’s attributes have values assigned to them. These values are usually entered by the object
administrator at object creation time.
During the object lifetime, a user may need to redefine the object’s attribute values. The user might
also want the redefinition to be applied to one type of usage of the object, and not applied to others.
In such cases, there are two perspectives in ACM in which the redefinition is valid:

Accounting Module WSS Accounting Concepts Guide

4 Global accounting support
4.7 Attribute overriding

•

The extension chart perspective

•

The ledger perspective.

This means that the effective attribute value for a user can be different from the native attribute
value depending on the perspective in which the user operates, and in which the value redefinition
(attribute overriding) is done.
Changing the object’s attribute values can be performed by a privileged user. It is the user’s
decision (depending on user privileges) if the required change should be valid in the extension chart
perspective or in the ledger perspective. This means that the user is responsible for selecting the
proper perspective.
The process of evaluating an attribute value is responsible for selecting the effective attribute value
according to the perspective in which current user (or action) operates. There are basically three
perspectives:

•

The native perspective

•

The chart perspective

•

The ledger perspective.

The native perspective is usually a perspective of the object itself. For instance, the native
perspective for a master chart account attribute is the master chart account. The attribute holds its
value regardless of any perspective. This value is stored along with the object itself – this attribute
is called the native attribute.
The extension chart perspective is a perspective that overrides the native perspective. For
example, an attribute of a master chart account is set in the extension chart perspective. A value
assigned to the attribute is valid only when a user operates in the extension chart perspective. If the
perspective is set to another extension chart or to the master chart, then the valid value is the value
specified in the object’s native attribute.
The ledger perspective is the most specific perspective. The ledger perspective overrides the
native perspective and the extension chart perspective. The attribute values set in the ledger
perspective are available only to the ledger. If a process operates in a different ledger or in a chart
perspective, then the valid value is the value specified in the object’s native attribute or the attribute
value defined in the extension chart perspective.
The attribute value is evaluated against the perspective in the following order:
1. The ledger perspective
2. The extension chart perspective
3. The native perspective.
Not all attributes of an object have the option of being overridden. In editors, a user can see the
native attribute value as well as attribute values overriding the original value in chart or ledger
perspective.

Chapter 5

Accounting processing

5.1 TRM accounting pre-processing
TRM Accounting Pre-processing is the part of TRM responsible for interfacing with ACM. It is based
on accounting inputs and accounting events.
Accounting input is elementary information defining that, for a given date and transaction, some
accounting events may be generated. The exact moment of accounting inputs generation is defined
by rules within a transaction flow. Accounting inputs are Result Method-dependent; this means that
if a transaction is treated by two accounting standards in parallel, accounting inputs for each
standard are created.
Accounting inputs are processed by input handlers, which results in accounting events (none, one or
more from one input). An accounting event is a standardized structure of accounting data, and
keeps all necessary information for its processing (mapping to accounts, posting to vouchers) in
ACM.
The set of accounting inputs to be processed is defined by handlers assigned by the accounting input
rules. The way that input is transformed into events is defined by handlers that are assigned via the
accounting event rules. Since accounting inputs are accounting standard-dependent, the accounting
events are standard-dependent too. This means that even if the accounting event might be the
same in two or more accounting standards, they are created for each standard separately. The
concept of Accounting Inputs and Events is the same for both basic TRM bookkeeping types – Daily
and Closing the Books.
TRM accounting events are generated by two activities:

•

TRM Daily Events Generation

•

TRM CTB Events Generation.

Both activities are started with the following three key starting parameters:

•

Due Date

•

Portfolio

•

Result Mode.

Accounting events are processed by ACM.

5.2 CMM accounting pre-processing
Processing in CMM is accounting standards-independent: each transaction is processed in CMM just
once (therefore it is necessary to ensure that the TRM result methods of just one result mode are
configured as payable; that is, not marked as Not Payable).
CMM Accounting Pre-processing is the part of CMM responsible for interfacing with ACM. The
interface is based on accounting events. An accounting event is a standardized structure of
accounting data, and keeps all necessary information for its processing (mapping to accounts,
posting to vouchers) in ACM.
The processing in CMM consists from several steps: for example, capturing, authorizing, realizing,
etc. CMM allows you to configure the step(s) in which the accounting events should be generated.
This enables you to post accounting entries; for example to suspense accounts at the moment of

Accounting Module WSS Accounting Concepts Guide

5 Accounting processing
5.3 ACM accounting entry processing

capturing the transactions in CMM, and their rebooking to the final cash account after their
reconciliation.
Since CMM is accounting standards-independent, all events are generated only once. Where the
events are needed for more accounting standards, they are multiplied during their loading into ACM,
and stored for all ledgers used by the same owner.
The only exception to the interface concept based on accounting events is the processing of
unrealized results from CMM. Unrealized results in CMM (currently only accrued interest from the
cash account in the in-house bank) are not stored in the database either as key figures or
accounting events. They are calculated and directly turned into accounting entries in ACM whenever
the appropriate activity is executed.
CMM accounting events and unrealized figures are generated by two activities:

•

CMM Daily Events Generation

•

CMM CTB Events Generation.

Both activities are started with the following two key starting parameters:

•

Due Date

•

Ledger.

Accounting events are processed by ACM.

5.3 ACM accounting entry processing
This chapter focuses on the description of accounting entries processing in ACM only. All key ACM
static entities are described in the chapter on Global Accounting Support.
ACM processing consists of the following basic steps:

•

Accounting Event Takeover

•

Entries Aggregation

•

Mapping to Accounts

•

Grouping to Vouchers

•

Voucher Finalizing.

5.3.1 Accounting event takeover
ACM gets Accounting Events via TRM/ACM and CMM/ACM interfaces that are triggered from ACM.
Accounting events arrive at ACM containing enough detail so there is no need further access to TRM
or CMM. The accounting data comes into ACM at the transaction/cashflow/key figure level. This
would allow, for example, direct referencing to the source (transaction, cashflow) in the originating
system.

5.3.2 Entries aggregation
As mentioned above, the Accounting events arriving at ACM are highly detailed. As this level of
detail level is often redundant for accounting, ACM allows you to define aggregation rules for
aggregating the accounting entries.
The entries aggregation rules can be split to two basic categories:

•

Aggregation of daily entries

•

Aggregation of CTB entries.

While ACM provides a default set of aggregation rules for daily accounting, there are no aggregation
rules for CTB entries. Therefore the CTB entries are posted at the most detailed level by default.

5 Accounting processing
5.3 ACM accounting entry processing

Under normal circumstances, there should be no need to change the setup of aggregation rules for
daily entries.

5.3.3 Mapping to accounts
The entries that were prepared in the previous steps (takeover and entries grouping) are the subject
of mapping to accounts processing. During this process, the posting accounts and voucher types are
assigned to the entries. Depending on the structure of the actions defined for a particular mapping
rule, the processing entry may be split to more entries (because of different proportions for different
cost centers, for example) or multiplied to more entries (if more actions with proportion 1 are
defined for example, for CTB mapping rules).
An ACM Mapping Rule consists of the:

•

IF part, that allows for matching Accounting Entry attributes such as transaction and cashflow
type, counterparty, portfolio, bank, bank account, configurable parameters, etc.

•

ACTION part that specifies the assignment of the Entry to the account, multiplication of the
Entry amount by a proportion, and Entry allocation to the cost center, project, etc. There may be
more than one ACTION part for one IF part.

Each non-mapped entry is compared with the IF part of the accounting rules. If the entry matches
the rule (that is, all parameters in the rule correspond to the parameters of the entry, an ACTION
part of the rule is executed. In the case where the entry is matched by more than one rule, the rule
with higher priority is selected.
A decision about the mapping of accounting entry to debit or credit is done by the specified account
side (DR or CR) in the action of the rule. The accounting entry is assigned to the debit or credit.

5.3.4 Grouping to vouchers
The goal of this step is to create a Voucher as an entity and to assign the voucher to the appropriate
accounting period. During this step the voucher balance is calculated. Non-balanced vouchers are
marked as not balanced and the user is informed about this in a report.
It is possible to configure a maximal rounding difference amount in ACM.
The conditions for grouping entries to vouchers are rule-based. ACM provides a default set of such
grouping rules and under normal circumstances, there should be no need to change the setup.

5.3.5 Voucher finalizing
This last ACM processing step assigns a rich voucher number to the pre-grouped vouchers. The
format of voucher number is configurable. Voucher number represents an unbroken voucher
number sequence and is unique for a given ledger. The rich voucher number is generated only when
the posting of vouchers is set to state Final.

Accounting Module WSS Accounting Concepts Guide

5 Accounting processing
5.3 ACM accounting entry processing

Chapter 6

Advanced accounting features

6.1 Account balances revaluation
Due to the volatility of the FX rates, for the accounts containing the entries in document currencies
different from a booking currency, the account balances in a booking currency do not have to reflect
a real situation. The adjustment of the balance in booking currency reflecting the latest FX rate can
be generated by the Account Balance Revaluation activity.

6.2 End of year accounting
Clearing of P/L accounts at the end of a fiscal year is managed by the Accounting End of Year
activity.

6.3 Zero sweeping
6.3.1 Introduction
Zero-sweeping is a functionality supporting the booking to some accounts depending on balance in
booking currency of an associated account. Balances are calculated in booking currency from the
entries in FINAL vouchers only. ACM supports two types of zero-sweeping:
1. Transaction zero-sweeping, where the balances are calculated per the reference IDs and the
Origin Entity (e.g. TRM transaction number).
2. Account zero-sweeping where the balances are calculated just per accounts.

Note: One account can be treated either in the transaction zero-sweeping or the account

zero-sweeping, i.e. both zero-sweeping types cannot be used for the same account.

Warning:

The setup of the zero-sweeping is very error-prone. Therefore it is recommended
after each change in the Account editor Zero Sweeping page to run the Chart of
Accounts Verification report which identifies the inconsistencies in such type of setup.
If any inconsistency for zero-sweeping setup exists in the chart, the voucher posting
process stops regardless of fact, if the voucher contains just accounts not affected by
zero-sweeping straightly.

6.3.2 Transaction zero-sweeping
Transaction zero-sweeping allows working with two connected accounts. The first account (primary
account) will not be used for posting until the balance in booking currency of the second account
(secondary account is zero, and vice versa. The balances are calculated in booking currency on the

Accounting Module WSS Accounting Concepts Guide

6 Advanced accounting features
6.3 Zero sweeping

connected accounts by the reference IDs and origin entities. For instance the balances for
accounting entries coming from TRM are calculated by a transaction number.

Note: Transaction zero-sweeping is typically used for the periodic CTB type for the booking to the
balance sheet accounts. The connected zero-sweeping accounts are typically identified by
the amount signs.

If an accounting entry is to be posted on the primary account and there is a balance on the
secondary account and that balance is bigger than the amount of the new entry, the entry will be
posted to the secondary account (and will decrease its balance).
If an accounting entry is to be posted on the primary account and there is still some balance on the
secondary account, but this balance is smaller than the amount of new entry, the remaining balance
of the secondary account will be re-booked to the primary account and the total new entry will be
booked to the primary account. The re-booking will be done in the following granularity:

•

reference ID

•

origin entity

•

bookkeeping type

•

document currency

•

project

•

cost center

•

instrument

Note: Just for a clarification: the balance of a secondary account is calculated in booking

currency per reference ID and origin entity only. Such balance is compared then with a just
posting entry). If zero-sweeping is be used, the zero-sweeping entries are created in the
granularity listed above (reference ID, origin entity, bookkeeping type, document
currency, project, cost center, instrument).

Let us assume we want to post a positive unrealized result, e.g. we want to book M-to-M profit.
Such entry should be booked to some P&L account, e.g. credit side of M-to-M Profit account, against
some balance sheet account, e.g. debit side of Positive Real Value account. Let us assume we
configured the transaction zero-sweeping between the balance sheet accounts, i.e. between the
Positive Real Value account and Negative Real Value account. For our positive entry we have one
mapping rule with a primary account Positive Real Value and with a secondary account Negative
Real Value.
Considering the balances of primary and secondary accounts, the following four possible situations
may occur for the positive accounting entry:
Primary Account
balance, e.g.
Positive Real
Value (BS)

Secondary
Account
balance, e.g.
Negative Real
Value (BS)

ZERO

NON-ZERO

Mapping Action for the positive accounting entry, bookings on
balance sheet accounts
The entry will be posted to the Primary Account (debit
side)
If the booking amount of the entry is smaller than the
balance of the secondary account, the entry will be posted
to the secondary account (debit side).
If the booking amount of the entry is bigger than the
balance of the secondary account, the balance of the
secondary account will be re-booked to the primary
account (DR of the Negative Real Value vs. CR of the
Positive Real Value) and the new entry will be posted to the
primary account (debit side).

6 Advanced accounting features
6.3 Zero sweeping

Primary Account
balance, e.g.
Positive Real
Value (BS)

Secondary
Account
balance, e.g.
Negative Real
Value (BS)

NON-ZERO

ZERO

NON-ZERO

Mapping Action for the positive accounting entry, bookings on
balance sheet accounts
The entry will be posted to the Primary Account (debit
side).
This is an invalid starting condition but it may happen if
you start using the transaction zero-sweeping later, i.e. for
given reference ID and origin entity there are already
posted entries on both primary and secondary accounts in
ACM.
ACM contains a self-correcting process, which in such
situation calculates a total balance of both associated
accounts including a new entry. Based on that total
balance it decides what account is the primary account and
re-books the balance from the secondary account to the
primary account.

For the bookkeeping of a negative unrealized result the following four situations may occur for the
the bookings to the balance sheet accounts:
Primary Account
balance, e.g.
Negative Real
Value (BS)

Secondary
Account
balance, e.g.
Positive Real
Value (BS)

ZERO

NON-ZERO

The entry will be posted to the Primary Account (credit
side)
If the booking amount of the entry is smaller than the
balance of the secondary account, the entry will be posted
to the secondary account (credit side).

NON-ZERO

ZERO

NON-ZERO

If the booking amount of the entry is bigger than the
balance of the secondary account, the balance of the
secondary account will be re-booked to the primary
account (CR of the Negative Real Value vs. DR of the
Positive Real Value) and the new entry will be posted to the
primary account (credit side).
The entry will be posted to the Primary Account (debit
side).
This is an invalid starting condition but it may happen if
you start using the transaction zero-sweeping later, i.e. for
given reference ID and origin entity there are already
posted entries on both primary and secondary accounts in
ACM.

Mapping Action for the negative accounting entry, bookings on
balance sheet accounts

ACM contains a self-correcting process, which in such
situation calculates a total balance of both associated
accounts including a new entry. Based on that total
balance it decides what account is the primary account and
re-books the balance from the secondary account to the
primary account.
As mentioned in the tables above, in case the balance of the secondary account is smaller than the
amount of just posted entry, the system creates special zero-sweeping entries, which clean the
balance of the secondary account to the primary account. Those special entries has the following
key characteristics:

•

Description = Zero Sweeping.

Accounting Module WSS Accounting Concepts Guide

6 Advanced accounting features
6.3 Zero sweeping

•

Mapping Description = Zero Sweeping.

•

Flag = Account and secondary account swept.

Note: This flag is assigned only to the entry posted on the account which is swept, i.e. the
account from which the balance is to be rebooked.

•

Origin = ACM-ZERO-SWEEPING.

•

Origin Group = ACM

•

Special Treatment= ZERO-SWEEPING.

•

Document Amount = document balance of the account to be swept

•

Booking Amount = booking balance of the account to be swept.

•

Originating State = POSTED.

Most of the other entry characteristics, e.g. Reference ID, Instrument, Portfolio, are the same as on
the initial entry.
The special zero-sweeping entries are by default posted in one voucher together with new entries
which initiated the zero-sweeping entries generation.
Zero Balance Sweeping is applied each time when the shifting of voucher state is performed
(including its initial creation). For example, if the Accounting Processing is run to simulation, then
the Zero Balance Sweeping is run taking into account the actual account balances. During the
consecutive shift of the vouchers to the FINAL state the Zero Balance Sweeping functionality is run
again so the potential changes of balances between the run of Accounting processing activity and of
Shift Vouchers activity are taken into account.
ACM supports two ways of configuring transaction zero-sweeping:
1. via the accounts (page Zero Sweeping).
2. via the accounting mapping rules (page Action).
You should not mix these two ways. It is recommended to use the setup via the accounts in the
Account editor since this setup is easier, its consistency can be checked via the Chart of Accounts
Verification Report and it is easier if entering vouchers affected by zero-sweeping manually via the
Accounting Entry Manager.

6.3.3 Account zero-sweeping
Account zero-sweeping is a functionality allowing to re-book the debit balances of the "source"
account to a profit account and credit balance of the "source" account to a loss account. It allows for
instance to see the year-today profit either on a profit account (in case of profit) or on a loss account
(in case of loss). The result is reported just on one of them, the remaining one has a zero balance.
That type of re-booking is mostly done at the end of each accounting period and typically the
zero-sweeping entries are reversed at the beginning of the following period (except at year end).
However, since the account zero-sweeping process takes into account the balances on the “source”
account as well as the corresponding profit and loss accounts together, it produces always a correct
adjustment. Therefore the reversals in the next period are not needed to be done from the system
perspective at all.
There are two basic scenarios which the account zero-sweeping addresses:
1. It eliminates a need to summarize a profit account and loss account together to see a total result
in case you book profits and losses on the separate accounts.
2. It provides a solution to distribute a profit or a loss from a net profit & loss account to the profit
account or the loss account.
Using the account zero-sweeping in the both scenarios a total result is reported either from a profit
account or a loss account. The logic is based on the calculation of account balance (in booking
currency) of the associated accounts and the generation of needed re-booking entries between
them.

6 Advanced accounting features
6.4 Time to maturity

Account zero-sweeping is typically configured for P&L accounts in case of using the cumulative CTB
type; based on the account zero-sweeping you can report the periodic results (typically year-today)
either from the loss account or the profit account.

6.4 Time to maturity
The Time to Maturity (TTM) feature supports the disclosure of assets and liabilities according to their
remaining time to maturity. It allows certain assets or liabilities to be reported on different accounts
according to the different remaining times to maturity over their life-cycle. As a consequence, such
assets and liabilities might be re-booked from one account to another if a precondition (remaining
time to maturity) for a certain account is no longer valid.
Remaining time to maturity is calculated as a difference between the end date of the processed
period and the maturity date from the accounting entry (e.g. the maturity date for the TRM
transactions). Remaining time to maturity is calculated in years. ACM allows you to define certain
gaps, so called time bands, as the multiples of the year. A minimum length is 1 year. The time
bands can be defined for instance as "up to 1 year", "between 1 and 5 years", and "longer than 5
years". The time bands are grouped to the time band sets. Every ledger can use a different time
band set definition according to accounting standards requirements. For each defined time band you
can define a specific time band account. All such accounts are linked to a "leading" account to which
all the accounting entries are booked. The "leading" account together with the appropriate time
band accounts represent a time to maturity chain. You can define unlimited number of such chains,
e.g. you can define a specific chain for long-term loans, a specific chain for fixed bonds in EUR, etc.
There are two basic approaches to defining the account chains in ACM:
1. You can encode the link into the Account IDs, i.e. you can reserve some position in the account
ID for the time to maturity feature. For instance you can reserve the 5th position from the left in
the account ID for that feature and each character used on that position can be linked to a
specific time band.
2. You can define the account chain tangibly, i.e. you can link the leading account to the account
dedicated for the time band with the longest remaining time to maturity ("longer than 5 years"),
the account dedicated for the time band with the longest time to maturity you can link to the
account with the second longest remaining time to maturity ("between 1 and 5 years"), etc. In
such case you can use the account IDs of any format.

Note: It is highly recommended to use only one of these approaches within a single ledger.
All the accounting entries to be classified according to their remaining time to maturity are posted to
the corresponding "leading" accounts. You route such entries to the accounts based on the mapping
rules. By running the Time to Maturity Processing activity for a certain accounting period the system
checks the accounting entries on the "leading" time to maturity accounts, calculates the balances
per time bands, and calculates the balances on the time band accounts. Based on these balances
the appropriate time to maturity re-booking entries (adjustments) are created. They are created on
the following aggregated level:

•

account

•

time band

•

document currency

•

cost center

•

project

Note: The aggregation level of the time to maturity rebooking entries is consistent with the detail
of stored balances.

Accounting Module WSS Accounting Concepts Guide

6 Advanced accounting features
6.5 Open Item Accounting

If you want to see the rebooking entries on the most detail level (i.e. on the level of initial
bookings), you can use Time To Maturity Journal report.
You can define if the time to maturity entries should be reversed in the next accounting period of the
one for which the activity was run (event date is the 1st day of the next period). Since the time to
maturity logic takes into account the balances on the “leading” account as well as the corresponding
time band accounts together in order to produce correct adjustments – that means that reversals in
the next period are not needed to be done from the system perspective at all.
Another set-up option is a possibility to define whether the re-booking entries should be posted to
the individual time band accounts against the "leading" accounts or to the time band accounts
against some special transfer account(s). Each account chain can reference a different transfer
account. In addition, it is possible to define a default transfer account.

Warning:

You cannot combine an approach with transfer accounts with an approach without
the transfer accounts.

Based on these 2 possible configurations the following 4 basic scenarios are allowed:

Scenario #

Time to maturity
reversals in the
next period

Usage of the
transfer account

Yes

To set-up the time to maturity feature you have to:

•

Define a time band set with the individual time bands.

•

Assign the time band set to a ledger.

•

Decide whether to use a transfer account (optional).

•

Define the position(s) in Account IDs representing a time band classification (just in case the
time band classification is encoded in the Account IDs).

•

Define the time to maturity account chains in the Account editor.

The time to maturity entries are generated by the Time to Maturity Processing activity.
The configuration of time to maturity account chains depending on the definition of a time band set
can be verified in Time To Maturity Verification report.
The classification of the particular entries according the defined time bands can be viewed in Time to
Maturity Journal report.

6.5 Open Item Accounting
Open Item Accounting functionality allows you to match (group) accounting entries on certain
accounts; for example, matching bookings (pre-booked entries) on suspense accounts with their
reverses (clearing entries). A valid match is a collection of entries posted in vouchers in FINAL
satisfying the following conditions:

•

All entries of the match are posted on the same Open Item account.

•

All entries of the match have the same document currency.

6 Advanced accounting features
6.6 Cost centers and projects

•

Entries balance (to 0) in document amounts.

•

Only entries with non-zero document amounts are allowed to be part of a match.

A match is identified by a unique integer number (column Match ID). Entries that belong to the
same match must have the same Match ID value. Obviously, an entry may be part of at most one
match.
The Open Item Accounting functionality comes in two flavors. An activity ACM Open Item
Matching can be used to automatically detect potential matches based on several not configurable
conditions. Another option for creating matches is to use the new Accounting Matching Manager.

6.6 Cost centers and projects
ACM allows allocating the entries to cost centers and projects. All the accounting reports allow to
view the entries and/or balances per cost centers and projects.
The cost centers and projects can be assigned to entry either manually via the Accounting Entry
Manager or automatically via the accounting mapping rules.

6.7 Rebooking Accounting entries
The ACM Rebooking functionality allows you to linearly split one accounting entry to one or more
accounting entries and to re-book them from one (initial) account to another (secondary) account.
See the example below:

This feature is based on using a criteria called Rebooking Type. This criteria can be assigned to the
accounting entry either automatically via the accounting mapping rules or manually via the
Accounting Entry Manager.

6.8 Automatic Breakdowns
Automatic Breakdowns allows reduction in the number of mapping rules. Instead of defining the
mapping rules for each combination of mapping values, it is possible to define a limited number of
mapping rules with assigned a breakdown definition.
ACM supports three types of automatic breakdowns:
1. Account Breakdown
2. Cost Center Breakdown

Accounting Module WSS Accounting Concepts Guide

6 Advanced accounting features
6.9 counterparty code

3. Project Breakdown.

Note: They all can be combined together.
A detailed description of each type follows.

6.8.1 Account Breakdown
Account Breakdown simplifies the setup of mapping rules where the entries should be mapped or
posted to individual accounts depending on the value of a few mapping conditions (typically less
than four). For example, entries mapped to individual accounts according to the document currency
and counterparty.
Instead of defining a separate mapping rule for each combination of mapping values (the
combinations of document currencies and counterparties), it is possible to define counterparty and
document currency as a breakdown criterion, and to assign such a criterion to just one mapping
rule. The definition of posting accounts and the mapping of counterparties and document currencies
to account IDs and their structure must already be defined.
The configuration of account breakdown consists of the following steps:
1. Accounts definition: the definition of posting accounts for all breakdown values, i.e. the accounts
for all value mapping combinations
2. Breakdown Values mapping: mapping of breakdown values to IDs contained in the definition of
accounts IDs
3. Breakdown Criterion definition
4. Breakdown criterion assignment to the mapping rules.

6.8.2 Cost Center Breakdown
Cost Center Breakdown works in the same way as Account Breakdown, but for cost centers. Its main
purpose is also the same - decreasing the number of the accounting mapping rules.

Note: Account balances in ACM are calculated per posting accounts, posting periods, document

currencies, cost centers and projects. If you want to view the balances per subsidiaries to
which you lend money, then instead of defining a separate account for each subsidiary, it
is possible to link each subsidiary to a specific cost center.

6.8.3 Project Breakdown
Project Breakdown works in exactly the same way as the breakdown for the cost centers. Instead of
cost centers you do the definition for projects.

6.9 counterparty code
In some cases special identifications of counterparties, different from IDs used in TRM/CMM, may be
needed in accounting books. This special identification is represented by Counterparty Code field in
ACM (former Creditor/Debtor Code in GLM).
Information about the counterparty code is available in the following reports:

•

Entry State

•

Journal

•

This information is also visible in the Accounting Manager.

6 Advanced accounting features
6.10 Mapping events to entries

6.10 Mapping events to entries
ACM processes accounting entries for two key modules: TRM and CMM. These two modules are
interfaced with ACM via the accounting events.
Accounting Events in CMM are of just one type, i.e. accounting events for all CMM accountable
operations (cash records and bank transactions including CTB) are stored in single table. Accounting
Events in TRM are of two types: one type represents accounting events for standard TRM
transactions, another type represents accounting events for payment allocations. These two
accounting event types are stored in separate TRM tables (events for transactions in the
AccountingEvent table, events for payment allocations in the EntityEvent table).
Accounting events keep various set of information from the transactions/records they represent

Accounting Module WSS Accounting Concepts Guide

6 Advanced accounting features
6.10 Mapping events to entries

Chapter 7

Accounting entry manager

7.1 Introduction
Accounting Entry Manager (AEM) is one of two applications started from the Accounting Manager
application (Wallstreet Suite/Accounting/Process Management). The Accounting Matching Manager is
the second application. In other words, Accounting Manager is a covering application from which the
Entry Manager as well as the Matching Manager are started.
Accounting Entry Manager (AEM) is the application for managing the vouchers. You can perform
different actions related to vouchers and entries, for example:

•

Enter accounting vouchers and entries manually (this includes duplicating existing vouchers and
creating the vouchers from templates)

•

Reversing vouchers

•

Bundling the vouchers

•

Shifting the voucher states

•

Querying for vouchers and entries based on criteria specified for vouchers and/or entries.

It is also possible to start some tools from the manager, for example, ACM Bookkeeping Launcher,
or Ledger Cross Check. It also allows you to start the ACM reports.
All entry/voucher changes done via the Entry Manager are logged and visible from state Open
onwards.
Accounting Matching Manager (AMM) is the application intended for the managing of open
accounting items; it allows manual matching of debit entries with credit entries on the accounts with
a matching type (SUSPENSE or FLOW-THROUGH).
This chapter focuses on the description of the Accounting Entry Manager only. Many features of the
Entry Manager are applicable for the Matching Manager too, e.g. customizing the display or on
screen querying. These common features are described in this chapter only and they are referenced
from the chapter describing the Matching Manager.

Accounting Module WSS Accounting Concepts Guide

7 Accounting entry manager
7.1 Introduction

Chapter 8

ERP interface

8.1 Introduction
ACM is typically used as a sub-ledger from which you typically export the entries or account
balances to a target ERP system for further processing and reporting. Such export functionality in
ACM is called ERP Interface.

8.2 The ERP interface overview
8.2.1 ERP target
ERP target represents an ERP destination system. For each ledger you can define up to three ERP
targets.
ERP target allows a definition of the export configuration settings, defining what data is exported
and where, and how the data is delivered.
ERP target definition is linked to a particular ledger and ensures that the accounting data from the
ledger is exported to the specified ERP target once only.
The following diagram gives an example.

8.2.2 ERP target types
ERP target type defines how and where to deliver the exported data. The ERP interface provides two
built-in mechanisms for delivering the ERP data into a target ERP system. They are:

•

SAP_FI for posting the ERP data to SAP via SAP Business Connector or using SAP XI interface.

•

FILE for saving the ERP data to a file.

Accounting Module WSS Accounting Concepts Guide

8 ERP interface
8.2 The ERP interface overview

A detail description of each follows.

8.2.2.1 SAP_FI
This target type provides integration with SAP-FI installation, including:

•

The data transport and the calling of generic interfaces in SAP using the SAP Business Connector
or SAP XI interface.

•

Possibility of ACM communication with multiple SAP installations.

•

Handling the status of invoked operations in SAP within ACM including potential error messages
and their interpretation by corrective activities in ACM.

•

Pre-configured mapping (transformation) of ACM fields to the SAP-FI fields.

8.2.2.2 FILE
This target type enables data storage in XML format. Such file can be used for customer-specific
development of an interface to any system.

Note: Files are generated by ACM server (not by ACM client).

8.2.3 ERP export modes
The ERP export can be of two basic types defined as Export Mode:

•

Voucher mode.

•

Account mode.

Note: Within one ledger you can use just one export mode.
A detail description of each follows.

8.2.3.1 VOUCHER export mode
This mode puts accounting entries into the ERP export by vouchers. All voucher entries are always
transferred in the same ERP export. Additional parameters defined in the ERP Export Definition
Editor allows to configure transferring of more vouchers in one ERP export. In such case all entries
belonging to these vouchers are transferred together.
The VOUCHER export mode does not depend on accounting periods, i.e. you can transfer the entries
from open as well as closed accounting periods.
In this mode the ERP export contains accounting entries.

8.2.3.2 ACCOUNT export mode
This mode puts accounting entries into the ERP export by accounts. Each account in the Account
Editor has a property ERP Balance Transfer which defines whether the entries from the exported
account are transferred individually (entry by entry) or aggregated to account balances.
Within one ledger you can mix both types of ACCOUNT export mode, i.e. some accounts can be
exported by entries, some accounts can be exported by balances.

Note: The ERP documents are created separately for both ACCOUNT export modes: BY_ENTRY
and BY_BALANCE. This information you can see in the ERP Document Report, column
Document Type.

For both ACCOUNT mode options the entries in the ERP document are balanced against the mirrored
entry posted on a technical ERP-CLEARING-ACCOUNT, which is defined as a property in the Ledger
Editor. The mirrored entry is identified by description Technical Mirror in the ERP Document Items
Report.

8 ERP interface
8.2 The ERP interface overview

8.2.3.2.1 ACCOUNT export mode by entries
If export mode is configured as ACCOUNT and the account field ERP Balance Transfer is configured
as NO, the ERP Document contains accounting entries from the exported account balanced by a
technical entry with ERP-ENTRY-CLEARING-ACCOUNT defined as a ledger property.
The ACCOUNT export mode by entries does not depend on accounting periods, i.e. you can transfer
the entries from open as well as closed accounting periods.
In this mode the ERP export contains accounting entries.

8.2.3.2.2 ACCOUNT export mode by balances
If export mode is configured as ACCOUNT and the account field ERP Balance Transfer is configured
as YES, the ERP document contains account balances from the exported account balanced by a
technical entry with ERP-BALANCE-CLEARING-ACCOUNT defined as a ledger property.
In this mode the ERP export contains account balances movements. The entries representing the
account balances movements in the ERP Document Items Report have a description Bal. Mv.
The ledger account movements (balances) are exported per the following dimensions:

•

Accounting period.

•

Cost center.

•

Project.

•

Document currency.

•

Debit/credit (i.e. it actually exports account movements per DR and CR side).

Note: You can export the account movements from closed periods with calculated balances only.
Such periods are identified by period state Closed in the Period for Ledger Report.

Note: If you mix the ACCOUNT export mode by balances with mode by entries and you run the

export activity for not closed period, the ERP document by entries is created anyway. The
ERP document by balances is not created and you get a message about the not closed
period in the Accounting Activity Log Report.

If some ERP document unit containing the account movements is posted and the appropriate
accounting period is re-opened for additional vouchers, you must run the ERP export for such period
again. In such case the affected document unit is reversed and new document unit is created.

Note: The system does not reverse the whole ERP document, it reverses just the smallest piece

of data, i.e. only the affected document unit(s). For instance, if account movements were
exported per two cost centers, but additional entries after a period reopen were posted
just for one cost center, only the document unit(s) with this cost center are reversed.

The link between the initial document unit and its reversing document unit is visible in the Document
Unit Report, column Reversed Document Unit System ID (the reversing unit contains the ID of the
unit to be reversed).

8.2.4 ERP target states
The ERP Interface exports and delivers final accounting data to the target systems. During this
export and transferring of accounting data (Vouchers and Entries), the system sets the ERP State to
each processed individual voucher and entry. The ERP State on each Voucher or Entry describes the
status of a Voucher or Entry from the Target perspective. Since ACM supports up to three
independent targets to be defined on Ledger, all accounting entities (Vouchers and Entries) have
three fields for showing the ERP states. For example, to check if voucher XY has been posted to ERP
in Target_1, you simply fetch the particular voucher in Accounting Entry Manager or Journal Report
and look at the field “ERP Target 1 State”.

Accounting Module WSS Accounting Concepts Guide

8 ERP interface
8.2 The ERP interface overview

ERP States on Voucher and Entry reflects the Document State. New Vouchers and Entries are always
allocated the state NOT_EXPORTED. Once the Voucher/Entry has been exported, and a new
Document has been created, all related entries get the ERP State EXPORTED or
BALANCE_EXPORTED. As soon as the Document is successfully posted (saved) to the target system,
these entries get ERP_POSTED or BALANCE_POSTED state. If some errors appear (e.g. a target
system refused a document) the document and also the Vouchers and Entries contained in this
document get state ERROR or state BALANCE_ERROR.

8.2.5 ERP document
The output of the ERP interface is represented by ERP Document. The ERP Document represents
the set of entries (ERP Document Items) and as a total it is balanced to zero. These documents
are then delivered to a target system using the proprietary ERP vendor’s API. The ERP document can
exactly match ACM voucher or hold another set of entries which meet specified grouping criteria
(Export Mode).
How the ERP Documents are created from entries, how documents are transferred to target system,
and how documents are reversed if necessary, is defined in per ERP target.
The system provides several reports that contain information on the ERP Document export state
and its content as well as information about not exported entities.
ERP Document Items are technically grouped into ERP Document Units. ERP Document Units are
not transferred to the target system, but on the ACM side ERP Document Unit serves as a balancing
unit inside ERP Document. While posting an ERP Document to a target SAP system (or saving to
specified file) ERP Document Unit is omitted and final representation looks like this:
3401F1_2005_00001 …..
USD40 ….
USD-40 …
……
At all points the ERP document has a state. When the document is created it gets one of the ready
states. Further processing moves document in the flow.

Chapter 9

Accounting reports

9.1 Introduction
Wallstreet Suite accounting solution is supported by many reports. They can be split to the following
categories:

•

Set-up data reports

•

Verification reports

•

Accounting process supporting reports

•

Basic accounting reports

•

Account balances reports

•

ERP reports

•

Hedge accounting reports

9.2 Set-up data reports
Almost all static data can be viewed via the reports.
Besides these reports showing your current accounting static data there is also a report allowing to
view, by whom the data were defined and how/who/when modified them. All these information are
available via the Accounting History Log Report.
All these reports are available from the Wallstreet Suite Application Manager/Accounting/Set-Up
Reports. All the reports can be started from the Report Generator, menu File/Open by selecting the
appropriate report layout from the dialog too.

9.3 Verification reports
The ACM editors are designed to maximize validations at the moment of entering static data via
them, however, some validations can be achieved just by running the special setup verification
reports.

Note: It is strongly recommended that you execute the setup verification reports after
completing the ACM static data setup and after any update of them.

ACM provides the following setup verification reports:

•

Period Set Verification Report

•

Chart of Accounts Verification Report

•

Time To Maturity Verification Report

•

Ledger Verification Report.

Accounting Module WSS Accounting Concepts Guide

9 Accounting reports
9.3 Verification reports

•

Ledger Verification for Ledger Group Report

•

Voucher Sequence Verification Report

•

Voucher Sequence Verification for Ledger Group Report

All the verification reports are available from the Wallstreet Suite Application
Manager/Accounting/Verification Reports.
There are some other reports which provide some sort of verifications, but which do not occur in the
Verification Reports menu folder. They are:

•

Accounting Mapping Rule Tree Report

•

Accounting Statement Template Report

Chapter 10

Viewing accounting balances

10.1 Balances granularity
10.1.1 Introduction
ACM allows to view accounting balances and movements only in granularity (dimensions) in which
the figures are stored in the database.
The system supports 3 basic granularity sets:

•

Fixed balances
They represent balances for fixed dimensions; balances per fixed dimensions are stored
automatically always and you do not require any additional setup. The fixed dimensions are:

•

–

Ledger

–

Posting account

–

Posting period

–

Document currency

–

Cost center

–

Project

Flexible balances
They represent balances per additional 10 configurable dimensions, which extend the fixed
dimensions. Typical examples of such dimensions are:

•

–

Counterparty

–

Instrument

–

Entry parameters (0 - 19)

–

Portfolio

–

Etc.

Trade level balances
They represent additional 4 dimensions which extend the fixed dimension. They are calculated
per:

–

Logical Reference ID

–

Logical Reference ID Origin

–

Leg Group

–

Leg (aka leg instrument).

Trade level balances can be configured independently on the definition of flexible balances.
Two very important notes follow:
1. Regardless of the balance dimension types, only accounting entries from FINAL
vouchers affect the stored balances figures in the database. However, most of the
applications displaying the balances allow to view the balances affected by vouchers

Accounting Module WSS Accounting Concepts Guide

10 Viewing accounting balances
10.1 Balances granularity

in different voucher states too (starting parameter Minimum Voucher State). If it is
requested, the effect of such vouchers is added to the stored balances; that
calculations is performed just on-the-fly and depending on the number of such entries
it may prolong a response time of applications showing the balances.
2. Even the balances are stored only in the granularity of dimensions listed above, there
are other two dimensons per which you can view the balances. They are:
a. Event Date
You can view balances in the granularity of fixed dimensions for any entry Event Date. Such
balances are available only in reports.
b. Posing Date
You can view balances in the granularity of fixed, flexible and trade level balances for any
voucher Posing Date and/or a Posting Dates range.
Also note that besides viewing the balances via the graphical user interfaces, ACM contains so called
Accounting Balances Snapshot API providing balances in the most detail granularity in the XML
format. For details see the ACM Administration Guide.

10.1.2 Fixed balances
10.1.2.1 Dimensions
By default, ACM stores balances per the following entities (dimensions):

•

Ledger

•

Posting account

•

Posting period

•

Document currency

•

Cost center

•

Project

Balances per these dimensions are stored without a need for any system configuration; you cannot
change it. Any combination of these dimensions is a key for accessing the balances.

10.1.2.2 Configuration
For storing the accounting balances in the granularity of fixed dimensions you do not need to
proceed any extra step. The balances are provided by default.

10.1.2.3 Reflection in activities
Fixed balances dimensions are reflected by all the ACM activities working with the balances,
namely:

•

Account Balance Revaluation

•

Account Zero Sweeping

•

Accounting End of Year

•

Time to Maturity Processing

10.1.2.4 Reflection in ERP export by balances
The ACM/ERP Account Export Mode by balances provides balances on the level of fixed balance
dimensions.

10 Viewing accounting balances
10.1 Balances granularity

10.1.2.5 Balances life cycle
Since there are no configuration steps needed for getting the balances per fixed dimensions the
balances are valid all the time.

10.1.2.6 Where visible
Accounting balances and movements per fixed dimensions are available in all the tools displaying
the accounting balances.

10.1.3 Flexible balances
10.1.3.1 Dimensions
Besides the fixed dimensions there are another 10 configurable dimensions per which the balances
can be stored and provided. The functionality around these 10 additional balances dimensions is
called flexible balances.

Note: Instead of defining the flexible balances you can map the other wanted dimensions (e.g.

counterparty, instrument, etc.) to an account, cost center or a project; you can use the
breakdown feature for simplifying that mapping - see 8.7 Defining Automatic Breakdowns
on page 440.

10.1.3.2 Configuration
Balances per additional (flexible) dimensions are not provided by default. Their configuration
consists from two steps:
1. Flexible balances definition
2. Flexible balances definition assignment on account

Warning:

There can be at most 10 flexible dimensions defined per system; they are calculated
as a distinct from all the definitions, i.e. in all the defined definitions together you
may have at most 10 different dimension data sources. If you use the same
dimension data source in more definitions, it is counted just once. The statistics of
used dimension data sources and the remaining count to 10 is shown in the editor
section "Dimensions Overview".

10.1.3.3 Flexible Balance Dimensions
In this tab you define the dimensions per which the flexible balances are calculated for given Flexible
Balance Definition. Following are supported entry dimensions which can be used for flexible
balances:

•

Bank,

•

Bank account,

•

Bank account currency,

•

Bank account holder,

•

Bookkeeping Type,

•

Counterparty,

•

Counterparty code,

•

Counterparty group,

•

Entry Parameter 0 ... Entry Parameter 19,

•

Figure,

Accounting Module WSS Accounting Concepts Guide

10 Viewing accounting balances
10.1 Balances granularity

•

Instrument,

•

Instrument Group,

•

Issuer,

•

Issuer group,

•

One time counterparty,

•

Portfolio,

•

Tag,

•

Transaction Currency,

•

Transaction Currency 2.

10.1.3.4 Reflection in activities
Fixed balances dimensions are reflected by all the ACM activities working with the balances,
namely:

•

Account Balance Revaluation

•

Account Zero Sweeping

•

Accounting End of Year

•

Time to Maturity Processing

10.1.3.5 Reflection in ERP export by balances
The ACM/ERP Account Export Mode by balances does not handle balances in the granularity of
flexible balances.

10.1.3.6 Balances life cycle
It is assumed that the flexible balance definitions are set-up as one of the initial steps during the
accounting implementation projects and remain unchanged. Note that when new accounts are
defined, no special action from a user is typically needed for them since their effective Flexible
Balance Definition is inherited from the parent accounts.
However, it is possible to change a flexible balances definition or an assignment on accounts. Here is
a summary of what happens in such a case:

•

Flexible balances for affected ledger(s) are invalidated:

–

If a Flex Balance definition itself is modified, then flex balances for all ledgers using a chart
with this modified flex balance definition are invalidated.

–

If a Flex Balance assignment is created, modified or deleted, all ledgers using that affected
chart are invalidated.

–

Change done within an attribute overriding invalidates only the given ledgers.

–

The ledgers are invalidated even in the cases when the flex balances definition is are
changed for accounts on which no entry was posted yet.

–

New account does not invalidate the balances.

•

Fixed balances are not affected by any of the above actions and are always available.

•

If balances are invalid, the tools for displaying the balances inform about this situation.

•

You must recalculate the balances by running the Flexible Balances Recalculation activity.

•

When balances are recalculated, the tools for displaying the balances show the figures again.

•

Fixed balances are not affected by any change in the flexible balances definition and are
available permanently.

10 Viewing accounting balances
10.1 Balances granularity

•

The historical entries resulting from balances before these changes, for instance Balance
Revaluation, remain unchanged. End of Year results are the only results requiring an action after
the flexible balances definitions change; for adjusting the end of year entries in the new
granularity you must run the Transfer Account Balances activity.

In other words, there is one current definition of balances (per account) and all balances
figures (including historical periods) are provided respecting this setup. There is no time
dependency where until certain date balances would have some granularity and a
different one after this date.

Warning:

You should always look on the balances of a given fiscal year in the balances
granularity, which was used during that fiscal year.

10.1.3.6.1 Flexible Balances Recalculation
Flexible Balances Recalculation is an activity for recalculating stored flexible balances after a change
in the flexible balances setup.

10.1.3.7 Where visible
Accounting balances and movements per fixed dimensions are available only in the Accounting
Monitor or in the Trial Flex Balance reports.

10.1.4 Trade level balances
10.1.4.1 Dimensions
Trade level balances are additional 4 dimensions which extend the fixed balances dimension. The
Trade Level Balances are calculated per:

•

Logical Reference ID

•

Logical Reference ID Origin

•

Leg Group

•

Leg

Trade level balances are automatically stored per all four dimensions, i.e. an activation just per one
of the above listed dimensions is not possible. The activation is done per accounts.
Trade level balances can be configured independently on the definition of flexible balances.
A detail description of each trade level balance dimension follows.

10.1.4.1.1 Logical Reference ID
Logical Reference ID represents a unique identification of the logical transactions, which together
represent a business case, e.g. an early expiration of a transaction in TRM is represented by two
transactions, which are linked by unique Logical Reference ID.
Logical Reference ID is an information available on the ACM entries. Its value is automatically filled
only for entries resulting from the TRM events (entries with Origin Entity TRM-TRANSACTION). The
concept is not applied for entries resulting from the CMM accounting events.
From TRM-TRANSACTIONS the logical reference ID is filled at the moment of the accounting event
take over only for entries with non-sellable instruments; they are the instruments with None or not
defined (empty) Selling method in the Result Editor.
Logical Reference ID is the same for all the TRM transactions from the linked business case. This
number is in TRM represented by the Continuation Number (idim_5 on the level of TRM accounting
events), which is the first transaction in the chain of transaction actions, e.g.:

•

Early expiration (full or partial) is considered as identical logical transaction with the original one

Accounting Module WSS Accounting Concepts Guide

10 Viewing accounting balances
10.1 Balances granularity

•

Roll over (full, partial, with capital increase, etc.) is considered as identical logical transaction
with the original one

•

Option Exercise is considered as an identical logical transaction with the original one

•

Call of a callable bond is considered as identical logical transaction

•

Conversion of a convertible bond is considered as identical logical transaction

•

Counterparty Conversion is considered as identical logical transaction

The handling of Logical Reference ID for manually entered entries/vouchers via the Accounting Entry
Manager is following:

•

Duplicate of an entry/voucher
Value in the Logical Reference ID field (as well as the value in Leg Group, Leg, Continuation
Number and Logical Reference ID Origin) of the source entry is copied to the new entry; their
values can be changed to any value or deleted; no validation is applied.

•

Newly created entry
Newly created entry, regardless its Origin and Origin Entity, is created with empty Logical
Reference ID (as well as empty Logical Reference ID Origin, Leg Group, Leg and Continuation
Number); their values can be filled by any value; no validation is applied.

In other words, the handling of Logical Reference IDs, Logical Reference ID Origin, Leg Group and
Leg field and also Continuation Number for manually created entries/vouchers is left on a user to fill
the appropriate value since there is no unique way of its determination.

10.1.4.1.2 Logical Reference ID Origin
Logical Reference ID is not unique transaction identification within the system. For instance, the
same Reference ID may come for a transaction from TRM as well as for a CLM payment advice. The
Logical Reference ID Origin field is there for ensuring the uniqueness. The possible values are:

•

ACM-TRANSACTION

•

BANK-TRANSACTION

•

CASH-RECORD

•

OTHER

•

PAYMENT

•

PAYMENT-ALLOCATION

•

TRM-TRANSACTION

For a copy/paste of the entry via the Entry Manager the same as described above for the Logical
Reference ID applies for the Logical Reference ID Origin.
When creating a manual entry, you can select any value from the above list. However, in vouchers
with Voucher Source ACTIVITY the Logical Reference ID is filled only on entries with Origin Entity
TRM-TRANSACTION.

10.1.4.1.3 Leg Group
Leg group is a technical ID of a transaction leg.
For a manual entry via the Entry Manager the same as described above for the Logical Reference ID
applies for the Leg Group field/value.

10.1.4.1.4 Leg
Leg represents an instrument of the transaction leg.
For a manual entry via the Entry Manager the same as described above for the Logical Reference ID
applies for the Leg field/value.

10 Viewing accounting balances
10.1 Balances granularity

10.1.4.2 Configuration
Trade level balances are activated per accounts by setting a value Yes in the Account editor, field
Balance by Logical Reference. Empty field is considered as No, unless the value Yes is inherited from
a parent account.
The following rules apply for the Balance by Logical Reference field:

•

Trade level balances can be activated on parent accounts too.

•

Balance by Logical Reference field is a subject to Chart and Ledger Attribute overriding

•

–

A native definition on an account may be overridden on a chart (extension) level or
ultimately on a ledger level.

–

In order to switch off the trade level balances on accounts, for which the trade level balances
are not required, you must set value No in the overriding field.

There is an inheritance mechanism applied in the account hierarchy in order to simplify the setup
as follows:

–

If an account has empty value in the Balance by Logical Reference field but its parent
account has some value there, this value is inherited from the parent account to the child
account.

–

If an account has some Balance by Logical Reference value (Yes or No) explicitly assigned, it
has higher priority than the value from its parent.

–

If a parent account has value Yes in the Balance by Logical Reference field, but you do not
require trade level balances for its child account, you must explicitly set value No for such
child account in this field.

•

The account hierarchy mechanism is applied first, the overriding mechanism
afterwards.

•

In order to check the effective setup, look to the Chart of Accounts and Chart of Accounts for
Ledger reports, column Balance by Logical Reference. This column shows an effective
configuration of the field after applying both mechanisms.

10.1.4.3 Reflection in activities
Trade level balances are reflected by Time to Maturity Processing activity only; only
accounting entries generated by this activity are generated in the granularity of trade level
balances. All other activities working with the balances (Account Balance Revaluation, Account Zero
Sweeping and Accounting End of Year) ignore this configuration and produce the entries in the
granularity of fixed and flexible balances only.

10.1.4.4 Reflection in ERP export by balances
The ACM/ERP Account Export Mode by balances does not handle balances in the granularity of trade
level balances.

10.1.4.5 Balances life cycle
It is assumed that the trade level balance are defined as one of the initial steps during the
accounting implementation projects and remain unchanged. Note that when new accounts are
defined, no special action from a user is typically needed for them since their effective Balance by
Logical Reference value is inherited from the parent accounts.
However, it is possible to change the Balance by Logical Reference value in the account editor. Here
is a summary of what happens in such a case:

•

Trade level balances for affected ledger(s) are invalidated.

–

If a Balance by Logical Reference value is modified within a chart, trade level balances for all
ledgers using this chart are invalidated.

–

Change done within an attribute overriding invalidates only the given ledgers.

Accounting Module WSS Accounting Concepts Guide

10 Viewing accounting balances
10.2 Balances figures

–

The ledgers are invalidated even in the cases when the flex balances definition is are
changed for accounts on which no entry was posted yet.

–

New account does not invalidate the balances.

•

Fixed balances are not affected by any of the above actions and are always available.

•

If balances are invalid, the tools for displaying the balances inform about this situation.

•

You must recalculate the balances by running the Flexible Balances Recalculation activity.

•

When balances are recalculated, the tools for displaying the balances show the figures again.

•

The historical Time to Maturity entries resulting from balances before these changes remain
unchanged and it is corrected when you run the Time to Maturity activity next time.

In other words, there is one current configuration of trade level balances and all balances
figures (including historical periods) are provided respecting this setup. There is no time
dependency where until certain date some Balance by Logical Reference setup was valid
and would be different after this date.

Warning:

You should always look on the balances of a given fiscal year in the balances
granularity, which was used during that fiscal year.

For the trade level balances recalculation after the changes in the Balance by Logical Reference field
configuration you must run the same activity as used for flexible balances. For details see 10.1.3.6.1
Flexible Balances Recalculation on page 53.The only difference is in the usage of Only Invalid
Balances field, which is applicable for trade level balances recalculations only.
If you are sure the balances configuration was done for trade level balances only, you can execute
the activity with Only Invalid Balances = Yes; in such case the activity will recalculate the trade level
balances only. If you see this value to No, then the activity will recalculate both flexible as well as
trade level balances.

10.1.4.6 Where visible
Accounting balances and movements per trade level balances are available only in the Accounting
Monitor. As an alternative there is a usage of Accounting Balances Snapshot API providing balances
in the most detail granularity including the trade level balances in the XML format. For details see
the ACM Administration Guide.

10.2 Balances figures
The combination of fixed + flexible + trade level dimensions represents a key to the balances.
Balances of “parent” accounts and periods (defined by account/period hierarchy) as well as the
balances affected by vouchers in other states than FINAL or balances per event or posting date are
calculated on the fly.
The following figures are available for both booking and document currencies:

•

Opening balance, i.e. life to period start date balance

•

Closing balance, i.e. life to period end date balance

•

Debit movement, i.e. a total sum of DR entries within a viewed period.

•

Credit movement, i.e. a total sum of CR entries within a viewed period.

10 Viewing accounting balances
10.3 Ways for viewing the balances

•

Total movement, i.e. a total sum of all DR/CR entries within a viewed period.

Note: Not all the figures are available in all the balance reports and also not all the reports allow
to view the figures in both currencies. See the description of the individual reports for
details.

If you view the balances for a fiscal year, the End of Year (EOY) period is automatically
excluded from it, i.e. closing balances for the fiscal year are reported without the affect
caused by entries posted in EOY period. A reason for this is as follows: you typically clear the
P&L account balances at the end of a year period so in the case of including such entries, the P&L
account balances for the fiscal year would show zeros.
If you want to see the closing balances for the EOY period you must view the balances for
the specific EOY period. Or you can view the accounting balances figures the first period following
the EOY period and to look at its opening balances; the EOY period's movements are included in the
balances provided for any period following the EOY period.

10.3 Ways for viewing the balances
ACM allows to view the balances either via the Accounting Monitor or via the reports. The reports
providing accounting balances are of four basic categories:

–

Trial balance reports

–

Trial flex balance reports

–

Balance query reports

–

Statement reports

A user permission for any balance report must be defined on the level of each ledger (see 2.6.3
Ledger Permission on page 72).

Note: Accounting Manager allows to view an account balance from the selected accounting entry
by using the Balance Snapshot command.

Accounting Monitor can be started from the Application Manager Accounting menu, subfolder Process
Management. All balance reports are available from the Application Manager Accounting menu,
subfolder Accounting Reports.
The brief overview and comparison of the Accounting Monitor and balances reports is summarized in
the table below:

Report feature
Supported balances
dimensions

Accounting
Monitor

Trial balance
reports

Trial flex
balance
reports

Balance
Statement
Query reports reports

Fixed

Yes

Flexible

Trade level
Balances in booking
currency

Yes

Balances in document
currencies

Yes

Balances in booking
currency converted to any
3rd currency

Yes

Accounting Module WSS Accounting Concepts Guide

Yes

10 Viewing accounting balances
10.3 Ways for viewing the balances

Accounting
Monitor

Trial balance
reports

Trial flex
balance
reports

Balance
Statement
Query reports reports

Balances for more
accounting periods in one
view

Yes

Yes, but only
for 4 periods
at once

Balances for more
accounts in one view

Yes

Balances for an event
date or a event date
range

Yes in Event
Date Balance
Query report

Balances for a posting
date or a posting date
range

Yes

Additional Grouping, i.e. a
possibility to view
balances per particular
balances dimension
values (e.g. by cost
centers, projects, flexible
balances)

Yes

Yes, but only
by cost
centers or
projects (not
for both at
once).

Yes, up to
three fixed
and/or flexible
dimensions at
once.

Yes, but only
by cost
centers or
projects (not
for both at
once).

Balances for a specific
dimension value, e.g. for
a cost center CC-1, for
instrument
BOND-TTM-20101111

Yes, for values
from any fixed
or flexible
dimension; no
limitation

Yes, but only
for specific
cost center
and/or project

Yes, for any
specific cost
center, project
or values from
3 specific
flexible
dimensions

Yes, but only
for specific
cost center
and/or project

Accounts in a hierarchy
view

Yes, but only
in Trial
Balance
Summary only

Yes (if
configured in
the report
template)

Balances for parent
periods

Yes

Balances for parent
accounts

Yes

Balances from entries in
other than FINAL state
(Minimum Voucher State)

Yes

Aggregated balances for
ledger groups

The trial
balance for
ledger group
reports do
not provide
any
aggregation.
They display
the balances
for all the
ledgers just
ledger by
ledger.

Yes (per
accounting
periods, not
per the even
date ranges).

Balances for more ledgers
in one output

Yes

Report feature

10 Viewing accounting balances
10.3 Ways for viewing the balances

Report feature
Balances per Logical
Reference IDs and Leg
Groups

Accounting
Monitor

Trial balance
reports

Trial flex
balance
reports

Balance
Statement
Query reports reports

Yes

The description of the Accounting Monitor and all the reports follows.

Accounting Module WSS Accounting Concepts Guide

10 Viewing accounting balances
10.3 Ways for viewing the balances

Chapter 11

Hedge accounting

11.0.1 Legislation
This chapter explains the extra steps you should take to comply the Wallstreet Suite with hedge
accounting matters defined by the following accounting standards:
1. International Accounting Standard No. 39 (Financial Instruments: Recognition and
Measurement), which is the part of the International Financial Reporting Standards (IFRS)
issued by International Accounting Standards Board (IASB).
2. FASB Statement No. 133 (Accounting for Derivative Instruments and Hedging Activities) and
FASB Statement No. 138 (Accounting for Certain Derivative Instruments and Certain Hedging
Activities - an amendment of FASB Statement No. 133), issued by Financial Accounting
Standards Board (FASB).

Warning:

Hedge accounting functionality in the Wallstreet Suite provides set of tools to aid
compliance with both standards in core plain vanilla and base scenarios only!

11.0.2 Glossary
This chapter lists a few basic accounting terms including their meaning and abbreviations as used in
the hedge accounting solution within Wallstreet Suite. Note that some of them are just the product
specific and as such may not be known out of the Wallstreet Suite community.
Hedging

A position establishing in attempt to offset the risk of some position (financial
transaction(s)) by another position (financial transaction(s)).

Underlying transaction
(aka hedged item)

It is a transaction bearing an unwanted risk; it is the subject of hedging.

Hedge transaction
(aka hedging
instrument)

It is a transaction (typically a derivative), which is used for hedging a risk of an
underlying transaction.

Hedge accounting

A synonym for the whole subject of hedging matters as defined by the above listed
accounting standards, i.e. it includes the hedge relations management, hedge
effectiveness calculations as well as the bookkeeping of accounting entries
resulting from the transactions in hedge relations.
Hedge accounting only applies to a portion of the all economic hedges and enables
gains and losses on the Hedge Transaction to be recognised in the same PL, and in
the same period, as offsetting losses and gains on the Underlying so as not to have
the PL volatile; i.e. the matching concept. The Accounting Standards requires that
the certain criteria shall be met in order to qualify for Hedge Accounting such as
Hedge Effectiveness Calculations, Hedge Documentation.

Hedge relation (or just
a hedge)

The join of hedge transaction(s) with underlying transaction(s) including specified
hedge characteristics, e.g. hedged risk, hedge type, hedge effectiveness
assessment method, etc.

Transaction
designation

A transaction is designated when it is a part of some hedge relation. It may also
mean a portion of a transaction, which is the part of a hedge relation.

Accounting Module WSS Accounting Concepts Guide

11 Hedge accounting
11.1 Solution coverage

Transaction
de-designation

It means a termination of a transaction designation, i.e. when a transaction was
designated in some hedge relation and that designation was ended.
In some situations it might be used for the whole hedge relation, for instance when
the whole hedge relation is ended before its initial hedge end date, than such
hedge relation is dedesignated.

Overdesignation

This term might be used in two situations:
1. A transaction is designated from more than 100% in a hedge relation
2. Amount on a hedge transaction is bigger than amount on an underlying
transaction.

Underdesignation

An opposite to Overdesignation

Theoretical derivative
(aka hypothetical
derivative)

It means something not really existing, which is simulated by a transaction in not
bookable portfolio. It represents a part or a portion of an entity’s gross position
(e.g. a transaction) which is allowed to be hedged and against which the
effectiveness is assessed, for instance, a hypothetical bond, a theoretical IRS, etc.
It is used as a substitute of an underlying transaction in a hedge relation in cases
when original underlying transaction cannot be used for the purposes of
effectiveness calculation, because its valuation cannot be retrieved for a hedged
part only.

Hedge strategy (aka
hedge program)

It serves as a link to some file/copybook, in which you describe in detail why, how,
what to process via hedge accounting. It is a link to other documentation about
some category of hedge relations.

11.1 Solution coverage
This chapter describes all key hedge accounting characteristics covered by the Wallstreet Suite
solution.

11.1.1 Supported hedge risks
Wallstreet Suite hedge accounting solution distinguishes the following hedge risks:
Hedge risk

Usage

FX-RISK

Hedging against the risk caused by FX rates volatility.

IR-RISK

Hedging against the risk caused by the volatility of interest rates.

PRICE-RISK

Hedging against the volatility of prices.

MARKET-VALUE risk

Hedging against the risk that the fair value represented by the market value
changes.

NET-MARKET-VALUE risk

Hedging against the risk that the fair value represented by the net-market value
changes.

11.1.2 Supported IRS hedging methods
The following are the hedging methods applicable for the IRS hedging:
Method

Description

Change in Fair Value

The calculation of effectiveness is based on the comparison of the entire
fair value of the IRS with the fair value of the underlying.

11 Hedge accounting
11.1 Solution coverage

Method

Description

Change in Variable Cash Flows

The calculation of effectiveness is split by Leg:
Fixed Leg of the IRS: the full change in fair value goes to the Equity/OCI
account.
Floating Leg of the IRS: the effective part of the change in fair value also
goes to the Equity/OCI account, whereas the ineffective part of the change
in fair value goes to P/L ineffectiveness, subject to the hedge designation.

Theoretical Derivative

The calculation of hedge effectiveness is based on the comparison of
change in fair value of the hedge and a theoretical swap.
To use this method, you must:
Enter a theoretical swap (with the same critical terms as the underlying)
into Wallstreet Suite.
Add the theoretical transaction to the hedge relation.
Wallstreet Suite then measures the fair value of the underlying as if it was a
swap.
If you select this method, and select Underlying in the field Relation Leg,
the field Theoretical Derivative becomes available in the Transaction page
of the editor.
Neither accounting entries nor Closing the Books are done for the
theoretical swap.

11.1.3 Supported effectiveness tests
To comply with Hedge Accounting standards, you must be able to prove that every hedge risk
component is effective. You do it by calculating a hedge effectiveness.

Note: If one of the components becomes ineffective the whole hedge must be considered as
ineffective.

Hedge effectiveness is calculated on regular basis (typically monthly or quarterly). There are three
types of effectiveness calculations supported by the system. Each type uses different method and
input data, and therefore is used for different purpose within the hedge accounting process.
For details see the table below:
Test name

Necessity

Description

Retrospective
Assessment

Mandatory

This assessment evaluates retrospective (achieved) effectiveness of a
hedge relation based on the specified hedge key figure. If effectiveness is
reached, hedge relation is marked as QUALIFIED. If no effectiveness
measurement is performed, this effectiveness is also used for splitting to
effective and ineffective part in accounting.
This assessment must be defined for each hedged risk within a hedge
relation.

Accounting Module WSS Accounting Concepts Guide

11 Hedge accounting
11.1 Solution coverage

Test name

Necessity

Description

Retrospective
Measurement

Optional.

This assessment evaluates retrospective (achieved) effectiveness of a
hedge relation based on the specified hedge key figure. If hedge relation is
marked as QUALIFIED (by the effectiveness assessment), then the
effectiveness measurement is used in accounting for splitting by
effectiveness.
This assessment can be defined just optionally. However, if this
measurement is configured, then you must calculate it. Otherwise the split
by effectiveness in accounting would not be done.

Warning:

Prospective
Assessment

Optional.

If you select the same key figure and method for
effectiveness measurement and assessment, then
measurement is not calculated and used in
accounting. In order to get measurement calculated
and used in accounting, you must define a
different key figure or method or both than defined
for assessment.

Prospective effectiveness is measured only at one data point of transaction
state, either in past or in presence (but never in the future). For this
specified date (transaction valuation point) transaction is valued based on
simulated market data. This is main difference from the retrospective
valuation, where only real market data are used.
Prospective simulation of hedge key figures can be based on simulation of
due date rates or using historical rates or combination of both approaches
where historical rates are simulated.
This assessment is optional. The output has informative meaning only and
does not have influence on a hedge qualification and splitting by the
calculated effectiveness. Though user can manually override qualification of
hedge taking into account calculated prospective effectiveness.
Prospective Effectiveness Assessment is defined via the Hedge Manager in
the Risk sub-window. Besides the Test Method and Key Figure you can
specify a Test Scenario, Gap Set and Gap too.

11.1.4 Supported effectiveness test methods
Wallstreet Suite provides several methods for calculating hedge effectiveness.
The test methods can be basically divided into two groups:

•

methods that do not perform a calculation (NONE, SHORTCUT, CRITICAL-TERMS), and

•

methods that do perform a calculation (DOLLAR-OFFSET, RATIO ANALYSIS, REGRESSION).

The following table lists all the methods, which can be used for a hedge effectiveness testing:
Method name

Method description

CRITICAL-TERMS

This method assumes no effectiveness testing. It indicates that the critical terms of the
transactions in the given hedge relation matches.
You manually check whether the date, amount, and currency of the hedge is the same
as those of the hedged transaction. By default 100% is assumed and activities to
calculate effectiveness can be skipped. If activity is run, then it is necessary to enter and
accept effectiveness in Hedge Effectiveness board, by default 0% is pre-filled.

11 Hedge accounting
11.1 Solution coverage

Method name

Method description

DOLLAR-OFFSET-C

Cumulative Dollar Offset.

u and
h denote the accumulated changes of key-figure values over the entire
Let
lifetime of the hedge summed over all the underlying and the hedging transactions,
respectively. The Dollar-Offset method determines to which extent are the changes of
the values of the underlying transactions offset by the changes of the values of the
edging transactions. This is achieved by calculating the ratio of
h and
u.

In other words, it checks the following:
- (Change in key-figure of hedge (derivative) /
Change in key-figure of hedged item (underlying))
x 100 = [85-120%]

Note: A period to be checked, i.e. can be changed by property Cumulative Start Date,
which can state different start of a period (last designation date, last hedging
hedge type date or their combination).
DOLLAR-OFFSET-P

Periodic Dollar-Offset Method
The same as Cumulative above, except that the period checked is the period you specify
for the activity Hedge Effectiveness Assessment (and Hedge Effectiveness Measurement,
if applicable).

NONE

This method assumes no effectiveness testing in Wallstreet Suite.
The effectiveness is typically tested outside of Wallstreet Suite, for example in a
spreadsheet application.

RATIO-ANALYSIS-C

The ratio analysis for simple statistical method for effectiveness assessment where the
change period is the entire lifetime of the hedge.
Let and denote daily changes of key-figure values for the day, summed over all the
underlying and the hedging transactions, respectively. The Ratio Analysis method is
similar to the Dollar-Offset method, but it evaluates the dollar offset ratio for each day
within the given period. The hedge is assumed to be effective if a sufficient number of
the obtained results is within the hedge boundaries.

RATIO-ANALYSIS-P

The same as Cumulative above, except that the period checked is the period you specify
for the activity Hedge Effectiveness Retrospective Assessment.

REGRESSION-C

Cumulative Regression Method
The regression analysis used especially for effectiveness assessment where the change
period is equal to the entire lifetime of the hedge. Compares hedge key figures using
linear regression analysis.
This method is not very suitable for effectiveness measurement (split by effectiveness
percentage), since the outcome is only defining how much underlying and hedge
transaction correlates. Therefore this method is often combined with Cumulative or
Periodic Dollar Offset Method for effectiveness measurement.
Let uk and hk denote daily changes of key-figure values for the day k, summed over all
the underlying and the hedging transactions, respectively. In a perfect hedge, any
change of the value uk should be fully compensated by an opposite change of the value
hk. In other words, if the points [uk,hk] are put into the plane, they should form a
straight line with slope -1. The Regression method tests this assumption by performing a
linear fit of the values hk as a function of the values uk.

REGRESSION-P

Periodic Regression Method
The same as Cumulative above, except that the period checked is the period you specify
for the activity Hedge Effectiveness Retrospective Assessment.

SHORT-CUT

It is applicable for FAS133 only. The hedge is considered to be 100% effective during the
entire life of the hedge, and no testing is performed. It indicates that the given hedge
relation should be treated with the short-cut method.
Changes in Fair Value of the underlying are copied and reversed from hedge transaction.
This always applies to the full fair value of the hedge. Therefore, even if the hedge is an
Interest Rate Swap, the fair value of the underlying would be the sum of the fair value of
the legs of the hedge.

Accounting Module WSS Accounting Concepts Guide

11 Hedge accounting
11.1 Solution coverage

For other details about the methods see appendix K.3 Effectiveness test method calculations on
page 1138.

Note: Some of the methods are just for documenting what method was used; with others, the

system will do a real testing. Note also that you should always use the same method for
the same kind of hedge (as specified in the Strategy Code field).

Warning:

Short Cut method is prohibited under the IAS 39.

Not all the methods are suitable for individual effectiveness measurement and assessment.
Cumulative and periodic version are distinguished only for retrospective assessment and
measurement. Usability of the particular hedge effectiveness methods is shown in the table below:
Prospective
Assessment

Effectiveness Methods

Retrospective
Assessment

Retrospective
Measurement

NONE

CRITICAL-TERMS
DOLLAR-OFFSET C / P

RATIO-ANALYSIS C / P

REGRESSION C / P

SHORT-CUT

Dollar Offset Method and Regression Method are used the most.

11.1.5 Supported hedge types
Hedge types determine how a hedging transaction will be processed in accounting. For the same
hedging relation, you can have two or more hedging types. This is because the hedging relations can
change over the time: for example, a hedge of a cashflow forecast becomes a hedge of a known
amount when the payment is invoiced, so a cashflow hedge changes to a fair-value hedge.
The following hedge types are supported:
Hedge Types

WSS Accounting Concepts Guide

Navigation menu

Versions of this User Manual:

Views

Navigation