In short, it's built around the idea of 'documents'. Each operation has an associated document.
For example, each sale would result in a 'Receipt for customer' document. A document can have linked documents (a receipt would typically be linked to a shipping order, for example). Documents are generally immutable and are not changed once created.
The second fundamental idea are 'registers'. They represent a temporal database which accumulates the changes that are made when documents are created. I.e. you can have a register tracking your bank account balance and when you write a check it would be decreased by the check's amount. However, since registries are temporal, you can actually view your balance at any point in time.
Including the future.
Which very useful for things like warehouse management for things like: "Assuming I don't get any new orders and my current shipping orders are completed in time, how much widgets would I have in store on Monday next week?".
Also, it's useful for backdated documents (which happen all the time in small business) - you can enter a document in the past and 1C would recalculate all the reports/documents that are affected by the corresponding changes in registers.
Then there's an easy ability to create forms bound to documents/registers (a bit like MS Access but more powerful) and design reports.
A system like this is actually not that hard to create. But the amount of details you need to know is staggering.
For instance, a lot of 'ledger' software has a built-in CRMs (it's only logical). But only very few of them have a temporal CRM which becomes crucial quite soon when you start dealing with customers changing their company names and/or addresses and you need to reproduce historical documents.