Skip to main content
Generic bridging summary
Search
Search Trust Tax (ONESOURCE) Support Help and Support.

This article applies to:

  • Product: ONESOURCE Trust Tax

Common questions

Find answers to some common questions for the generic bridge.

Data loads and tax-year updates

The tax year you update with data loads depends on the type of data file.
Month end
A
Month End
 data file is loaded to that month and year.
For example:
  • The October month end would be loaded as 10/31/2012, or the December month end is loaded as 12/31/2012.
Short
A data file that is not a month end file and is not a
Transaction Only
 file is considered a
Short Month
 file. The data file is logged into the system with the date the data was pulled.
For example:
  • A bank requests or schedules with the vendor to send a short file on Close of Business (COB) December 15. The client tells ONESOURCE the file is expected to be sent with data through December 15, 2012. ONESOURCE sees the posting dates through December 15 and logs the file into the system with this date. This date lets the client automatically run a worksheet without having to specify dates and picks up all postings through December 15, 2012.
When the processing account and beneficiary data are on a short file, the load logic adds this to the prior
Month End
 date.
For example:
  • Most clients send short files in January. The load logic reads it as a short file and will target the prior month end of the December 31, 2012 tax year for updating.
A new trust received on a short file is loaded with the short file’s month and year.
For example:
  • With a new account on January 15, 2013, the short file is loaded to the load month/year and is added new to the tax year 2013. This behavior usually occurs at year-end for calendar accounts and throughout the year for fiscal accounts.
Some clients are very sensitive to when the January month end file loads, because you begin loading to the new tax year. This causes the load to roll up to the current tax year if the account is not in the new tax year.

Computing prior year impact

The computing of a tax return affects the beneficiary record of subsequent tax years. For example, if you compute the 2012 tax return, the new tax year gets created. This includes any information needed for the next tax year. This usually happens year-end through the end of April except for fiscal accounts.
Each time you compute, the tax year is deleted and re-rolled with the most current compute information. This only happens if the next year hasn’t been computed. In addition, if new beneficiaries were added that don’t exist in the year being computed, they won’t be deleted. If you bridge tax year specific information to 2013 and you recompute the prior year (2012), the 2013 data is deleted and re-rolled from 2012. This happens regardless of any loads during 2013.
note
The 2012 return has been computed, and the February 2013 monthly data has been loaded. Notification has been received that something was wrong on a 2011 tax return and needs to be fixed and recomputed. This action will NOT cause a re-roll because the account was already computed in 2012.
Fiscal accounts
 are loaded to the Prior Tax year so that a midyear tax return can be computed. Example: An August fiscal account loading in February 2013 would load to tax year 2012 and when Month End September 2013 loads it will roll the account to 2013 if the tax return hasn’t yet been computed.

Record type 2 (Beneficiary Information)

If you're sending this record, then you need to follow with
Record Type 3Q
.

Updating CTF factors

Previously loaded CTF factors can't be updated or stopped with a subsequent load file. A
Record Type 7F
 can only correspond to a
Record Type 3[Blank]
. This means you can't match
Record Type 3U (Update to a Transaction)
 or
3S (Stops to a Transaction)
 to
Record Type 7F
 to update the CTF factors.

Place record type 25 (Co-Trustee) in relation to Record Type 2

Record Type 25
 should be placed after all the
Record Type 2
 and
Record Type 2O
 values. For example, you can send 2, 2M, 2O, 2, 2O, 25, 25, 25. Each co-trustee should only be sent once and there can be multiple
Record Type 25s
.
If there isn't a
Record Type 2
 for the account, then it should follow
Record Type 1
.

Taxpayer ID in Record Type 35 (Name/Address for Paid to and Paid By)

The taxpayer ID isn't required to load information, however, leaving this blank can cause future processes to fail. If it's left blank, the load logic attempts to match using the name.

Prior year and historical data not found

If you've sent a file to someone and they can't find the account for that year, then it's likely that the data was loaded but the prior year wasn't created. This happens because the load logic can't add a prior year if the current year already exists. You'll need to create the missing year in ONESOURCE Trust Tax before you can find the loaded data.

Record 7F tax codes

There aren't any restrictions on tax codes sent to
Record 7F (CTF)
, but only the following tax codes are treated as
gain distributions
. Other tax codes not mentioned are treated as
income distributions
.
  • 39
  • 40
  • 45
  • 46
  • 132
  • 133
  • 220
  • 103
  • 104
  • 100
  • 101
  • 510
  • 515
  • 597

Set the Sale of Collectibles flag

There is no direct, corresponding field in the
Generic Format
, which sets the
Sale of Collectibles
 flag, but the following scenarios describe when it is set during the load process:
  • Record Type 4
    only (without corresponding
    Record Type 5)
    • Federal Gain/Loss Term Indicator
       included in
      Record Type 4
       is only used by the load logic when there are no corresponding
      Record Type 5
      .
    • If the
      Federal Gain/Loss Term Indicator
       is equal to M (Long Term (collectibles held 12 months or longer, 28% tax rate)), the load logic sets the
      Sale of Collectibles
       flag on the sale and sets the term on the tax lot (which is created by the load logic) to Long Term 28%.
    • If the
      Federal Gain/Loss Term Indicator
       is equal to L (Long Term (capital asset held 12 months or longer, 20% tax rate)), and the asset’s
      Security Type
       on the application's database is set to
      Collectibles 28%
      , the load logic sets the
      Sale of Collectibles
       flag on the sale and sets the term as
      Long Term 28%
      .
  • Record Type 4
     with corresponding
    Record Type 5
     (can have multiple):
    • The
      Federal Gain/Loss Term Indicator
       on
      Record 4
       isn't used.
    • If the acquired date and sales date provided indicate sale is long-term and the asset’s
      Security Type
       on the application's database is set to
      Collectibles 28%
      , the load logic sets the
      Sale of Collectibles
       flag on the sale and sets the term as
      Long Term 28%
      .

Send a test file

You can send a test file by auto load or by manual load.
Auto load
: If you send the load file to your SFTP user ID and include the test PAN in the file name, this will be treated as a test file, and all the data will load in the test PAN.
Manual load
: You'll need to notify production staff that the file needs to be loaded as a test file.

Asset type assignments

Asset type is set based on certain tax codes for the 1st transaction loaded for an asset and is categorized as follows:
note
When a tax code isn't assigned, then the asset type defaults to
Other
.
Tax code
Description
986
Common fund
83,107,121,124,496,498
If the state or country of issue isn't CZ, GU, PR, or VI, it also includes 11 and 497
Municipal bond
3,10, 29, 39, 299, 495, 499, 501
Foreign asset
85, 123, 136, 137
If the state or country of issue isn't CZ, GU, PR, or VI, it also includes 11 and 497
Territorial bond
13, 494
U.S. government bond
906
Mutual fund
15 ,26, 48, 62, 72, 73, 74, 75, 76, 77, 112, 402, 403, 404, 405, 406, 407, 408, 409 ,410, 411
Rent or royalty
14
Schedule C (Business)
350, 352, 351, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 371, 372, 373, 375, 376, 377, 378, 379, 381, 382, 383, 384, 385, 386, 387, 388, 389
Schedule F (Farm)
Record 8K asset
Partnership (K-1)
16, 37, 38, 49, 61, 63, 64, 70, 106, 113, 966, 967, 968
Mineral

Stops and updates in the sales or transaction register

The
record overflow
 field on the load record is required when sending an update for previously loaded sales or transactions. It will contain a
U
 for update or an
S
 for stop.
If the prior transaction or sale is found, the
Stop
 or
Update
 field on the existing item is set to
Found Update
 or
Found Stop
.
If the prior transaction or sale isn't found, new items are created with the field set to
Added update
 or
Added stop
.
Reversal transactions or sales should be sent with the field record overflow cleared. There is a load option that can be used which will mark reversals and originals as stops. If used, the field will be set to
Reversal Stop
.

Accounts loading to 2 different years

Depending on the timing when the account was first bridged, the logic will create the account in 1 year or both. There is logic for new 5498 accounts, if loaded January through April the account will be created in both the current and prior tax year.

Determine the terms on a sale

The following calculations occur when Record 5 is provided:
The term of the lot is based on the
Record 5 Lot Acquired Date
 and the
Record 4 Trade Date
. A difference of 1 year or less is short term; otherwise, it is long term.
The lot price calculation:
Sales Price
 multiplied by (
Lot Units Sold
 divided by
Units Sold
). When it is the last lot of multiple lots, the lot price calculation is
Sales Price
 minus the total of all
Lot Prices
. When there is only 1 lot, the
Lot Price
 is equal to
Sales Price
.

Taxpayer ID not matching

If the
Taxpayer ID
 sent has
FOREIGNUS
 as part of it, it will be changed to
FORM1042S
 before loading. This applies to both
Record 2
 and
Record 2O
.
For example,
FOREIGNUS919
 will be changed to
FORM1042S919
.