> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tight.com/llms.txt
> Use this file to discover all available pages before exploring further.

# General Ledger

## 1. How it works

As explained in the [Accounting API docs](/v5.0/products/accounting), Tight's "Invisible" Double-Entry Accounting is enabled in the background for all users.

When you [create a user](/v5.0/getting-started/quickstart/user-creation) via the Tight API, and you specify their business type, Tight automatically generates a [chart of accounts](/v5.0/products/accounting/chart-of-accounts) for that user. As the user takes actions in your product, i.e. they send out invoices, classify expenses, and make tax payments, Tight creates the proper double-entry transactions into the user's General Ledger (GL) for accrual basis, cash basis, and modified cash basis.

## 2. What it enables

With a full-fledged General Ledger behind the scenes, and double-entry transactions being created automatically, you can provide your users with robust [financial reporting](/v5.0/products/financial-statements), [tax reporting](/v5.0/products/tax/tax-reporting), and [tax filings](/v5.0/products/taxes/tax-filing) with just a simple network call.

## 3. Getting the user's GL transactions

Most users will never need to look at a General Ledger. But, if your product serves accountants or bookkeepers, then they may want direct access to the General Ledger. At any time, you can [display the GL](/v5.0/embeddable-ui/accounting/general-ledger-component) or programmatically [retrieve the user's GL transactions](/v5.0/products/accounting/general-ledger).

On each entry, you may find the following attributes to be of particular interest:

| Field        | Description                                           | Format                                        |
| :----------- | :---------------------------------------------------- | :-------------------------------------------- |
| sourceTable  | Entity that originated the underlying GL transactions | String                                        |
| name         | Displayable name describing the entry                 | String                                        |
| tranDate     | Accounting date of the underlying GL transactions     | `yyyy-MM-dd'T'HH:mm:ss.SSSZ`                  |
| entryDate    | Date the entry was added                              | `yyyy-MM-dd'T'HH:mm:ss.SSSZ`                  |
| transactions | List of GL transactions                               | Array of transaction objects, explained below |

For each GL transaction, you may find the following attributes to be of particular interest:

| Field       | Description                                                                                                    | Format                         |
| :---------- | :------------------------------------------------------------------------------------------------------------- | :----------------------------- |
| accountNo   | Account number, referencing an account in the [Chart of Accounts](/v5.0/products/accounting/chart-of-accounts) | String (of numbers)            |
| accountName | Name of the account                                                                                            | String                         |
| drAmount    | Accounting [debit](https://en.wikipedia.org/wiki/Debits_and_credits) amount                                    | Numeric, with 2 decimal places |
| crAmount    | Accounting [credit](https://en.wikipedia.org/wiki/Debits_and_credits) amount                                   | Numeric, with 2 decimal places |

## 4. Adding journal entries

Most GL transactions can be handled by updating expense, income, invoice, bank transfer, and tax payment transactions accordingly. But occasionally, there may be an advanced use case where an accountant or bookkeeper wants to make a manual journal entry directly into the General Ledger. These transactions can be easily created in the [General Ledger embeddable user interface](/v5.0/embeddable-ui/accounting/general-ledger-component), or programmatically via API.

For example, if an owner was infusing \$100,000 into their single-owner S-Corporation, then the Paid-in Capital account would need to be increased.  To do so via API, simply look at the [user's chart of accounts](/v5.0/products/accounting/chart-of-accounts#3-getting-the-users-chart-of-accounts), and pull out the account number (`accountNo`) for each account. In this case 11100 corresponds to Bank Account Operating and 35000 corresponds to Paid-in Capital:

```curl theme={null}
curl \
  --request POST \
  --url https://sandbox.hurdlr.com/rest/v5/accounting/journalEntry \
  --header 'Authorization: Bearer ${access_token}' \
  --header 'Content-Type: application/json' \
  --data '{
    "journalEntry": {
      "tranDate": "2021-10-06T04:00:00.000Z",
      "name": "Capital infusion"
      "transactions": [
        {
          "description": "Capital infusion",
          "accountNo": "11100",
          "drAmount": 100000.00,
          "crAmount": 0
        },
        {
          "description": "Capital infusion",
          "accountNo": "35000",
          "drAmount": 0,
          "crAmount": 100000.00
        }
      ],
    }
  }'
```